Wine package guidelines (Português)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Status de tradução: Esse artigo é uma tradução de Wine package guidelines. Data da última tradução: 2019-06-19. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.
Diretrizes de pacotes do Arch

32-bitCLRCMakeCrossDKMSEclipseElectronFonteFree PascalGNOMEGoHaskellJavaKDEKernelLispMesonMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyRustVCSWebWine

Muitos programas do Windows ainda podem ser úteis no Linux e, portanto, podemos querer ter um pacote para eles. As diferenças entre os dois sistemas operacionais tornam essa tarefa um pouco complexa. Nesta diretriz, falaremos sobre binários do Win32, já que os projetos em que a origem está disponível geralmente são portados para o Linux.

Coisas para verificar imediatamente

  • Licença: a licença permite que o programa seja reempacotada?
  • Instalador: é possível instalar o programa silenciosamente? Melhor ainda, existe uma versão sem instalador?
  • Portabilidade e limpeza: é o programa portátil? É limpo?

Aqui dizemos que um programa é portátil se nunca escreve no registro ou fora de seu diretório; dizemos que um programa é limpo se nunca escreve em seu diretório, mas pode gravar suas configurações na pasta do usuário. Um programa também pode ser ambos (por exemplo, nunca escreve configurações) ou nem (por exemplo, ele escreve em seu diretório, escreve em volta, escreve no registro ...)

Licença

Geralmente, as licenças estão em um arquivo de texto no diretório de instalação. Se você não conseguir encontrá-los, tente seguir as telas durante a instalação. Se nada for dito sobre reempacotamento, vá em frente. O autor não se importa. Caso contrário, a licença geralmente não permite a remoção de arquivos ou não permite a reempacotamento. No primeiro caso, apenas tenha cuidado para que o processo makepkg não perca nenhum arquivo, você pode excluir arquivos desnecessários (por exemplo, desinstaladores) na fase post_install; no último caso, todo o processo de instalação deve ser feito na fase post_install. A fase build será apenas para copiar os arquivos de instalação.

Instalador

É muito mais fácil trabalhar com arquivos compactados como .zip do que com instaladores do Windows. Se você não tiver escolha, pois o autor insiste em distribuir seu programa com um instalador, pesquise na Internet se é possível instalar silenciosamente o software. MSFN geralmente é um bom lugar para pesquisar. Se não conseguir encontrar uma maneira, tente abrir o instalador com diferentes utilitários de desempacotamento; pode funcionar.

Portabilidade e limpeza

Um programa portátil não precisa de seu próprio sistema de arquivos em Wine, portanto, verifique em Portable Freeware se o programa que você está empacotando é portátil.

A diretriz em resumo

A ideia por trás do empacotamento de um programa do Windows é usar os arquivos do programa como meros dados que o Wine interpretará, assim como o bytecode da JVM e do Java.

Então vamos instalar o programa em /usr/share/"$pkgname" e o programa irá escrever tudo o que precisa em "$HOME"/."$pkgname". Tudo será preparado por um pequeno script salvo em /usr/bin/"$pkgname" que irá criar a pasta, prepará-la, se necessário, e finalmente iniciar o programa.

Nas próximas seções, nós vamos falar sobre cada etapa.

Desta forma, cada usuário terá suas próprias configurações e suas decisões não incomodarão outros usuários.

Instalando

Se o programa não tiver instalador, a instalação é uma mera descompactação de um arquivo; descompacte-o em "$pkgdir"/usr/share/$pkgname, certificando-se de que as permissões estejam corretas. Esses comandos servirão:

$ find "$pkgdir"/usr/share -type f -exec chmod 644 "{}" \;
$ find "$pkgdir"/usr/share -type d -exec chmod 755 "{}" \;

Se o programa não puder ser instalado da maneira mais fácil, você precisará criar um ambiente Wine:

$ install -m755 -d "$srcdir"/tmp "$srcdir"/tmp/env "$srcdir"/tmp/local
$ export WINEPREFIX="$srcdir"/tmp/env
$ export XDG_DATA_HOME="$srcdir"/tmp/local
$ wine "$srcdir"/installer.exe /silentoptions

Nós ainda não discutimos a portabilidade, mas se o seu programa não precisa das chaves de registro que ele modificou, você pode simplesmente copiar o diretório do:

"$srcdir"/tmp/env/drive_c/Program\ Files/nomeprograma

Caso contrário, você precisará copiar todos os arquivos de registro também e, eventualmente, os arquivos instalados pelo programa. O "$srcdir"/tmp/local conterá ícones de menu e arquivos da área de trabalho, você pode querer copiá-los no pacote. Se não existe uma maneira de instalar o programa silenciosamente ... Talvez você possa criar um arquivo .tar.gz e enviá-lo para algum lugar? Se nada for possível, force o usuário a seguir o instalador e espere que ele não estrague a instalação, faça algumas verificações antes de copiar cegamente uma pasta que pode não existir (por exemplo, o usuário pressionou 'Cancelar').

O script /usr/bin

Este script prepara a pasta de configurações e inicia o programa. Se o seu programa for portátil, ficará assim:

#!/bin/bash
unset WINEPREFIX
if [ ! -d "$HOME"/.nomeprograma ] ; then
   mkdir -p "$HOME"/.nomeprograma
   #prepare o ambiente aqui
fi
WINEDEBUG=-all wine "$HOME"/.nomeprograma/nomeprograma "$@"

Se for limpo, ele vai se parecer com isso:

#!/bin/bash
export WINEPREFIX="$HOME"/.nomeprograma/wine
if [ ! -d "$HOME"/.nomeprograma ] ; then
   mkdir -p "$HOME"/.nomeprograma/wine
   wineboot -u
   #copie o arquivo de registro se necessário
fi
WINEDEBUG=-all wine /usr/share/nomeprograma "$@"

Como você pode ver, no segundo caso não há preparação do ambiente. Na verdade, um aplicativo limpo será iniciado diretamente de /usr/share, pois não precisará gravar em sua pasta, portanto, suas configurações serão gravadas em algum lugar no sistema de arquivos emulado.

Se o aplicativo não for nem limpo nem portátil, as duas ideias devem ser combinadas.

Se o aplicativo não gravar configurações, ignore o if e inicie-o em /usr/share.

A tarefa de preparar o ambiente pode diferir muito entre os aplicativos, mas siga estas regras práticas: Se o programa:

  • só precisa ler um arquivo, faça um link simbólico para ele.
  • precisa escrever em um arquivo, copie-o.
  • não usa um arquivo, ignore-o.

É claro, o mínimo é só iniciar WINEDEBUG=-all wine /usr/share/nomeprograma "$@".

Geralmente, o ambiente será feito por link simbólico entre o diretório "$HOME"/.nomeprograma e os arquivos /usr/share/nomeprograma. Mas já que alguns programas do Windows são muito inconstantes em relação aos seus caminhos, você pode precisar vincular diretamente no diretório "$HOME"/.nomeprograma/wine/drive_c/Program\ Files/nomeprograma.

Claro que essas são apenas ideias para integrar aplicativos Win32 no ambiente Linux, não esqueça sua inteligência e bom senso.

Como exemplo, μTorrent é por padrão um aplicativo limpo, mas com uma etapa fácil pode ser usado como um arquivo portátil. Já que é um único arquivo e é bem pequeno criando seu ambiente do Wine (aproximadamente 5MB) é provavelmente um exagero. É melhor criar um link simbólico para o executável, criar o settings.dat vazio para poder usá-lo no diretório $HOME/.utorrent. Com a vantagem de apenas visitar a pasta .utorrent, um usuário pode ver uma cópia dos arquivos .torrent que baixou.

UnionFsFuse

Você pode considerar o uso do programa UnionFsFuse disponível nos repositórios oficiais como unionfs-fuse). UnionFsFuse permite manter o diretório base no /usr/share e colocar uma cópia dos arquivos do aplicativo necessários para escrever dentro de $HOME/.nomeprograma quase automaticamente.

Usar UnionFsFuse significa uma dependência adicional e requer o módulo fuse, o que nem todos os usuários podem carregar. No entanto, pode valer a pena se o aplicativo precisar de muitos links simbólicos ou se não estiver claro exatamente o que precisa ser escrito. Apenas certifique-se de montar e desmontar os UnionFs corretamente.

Um exemplo

Vamos fazer um pacote para o eMule. De acordo com Portable Freeware, eMule não é completamente portátil, pois ele escreve algumas chaves (inúteis) no registro.

Por outro lado, ele também não é limpo já que ele escreve seus arquivos de configuração e coloca seus downloads em sua pasta de instalação.

Por sorte, há uma versão sem instalador disponível.

Então, nós fazemos nosso PKGBUILD; a única dependência é o wine. O md5sums deve ser adicionado.

# Maintainer: Você <seuemail>
pkgname=emule
pkgver=0.49b
pkgrel=1
pkgdesc="One of the biggest and most reliable peer-to-peer file sharing
clients around the world."
arch=(i686 x86_64)
url="http://www.emule-project.net"
license=('GPL')
depends=()
depends=(wine)
makedepends=(unzip)
source=(emule http://prdownloads.sourceforge.net/emule/eMule$pkgver.zip)
noextract=()
options=(!strip)

build() {
  rm -f src/eMule"$pkgver"/license* #It is GPL

  install -d -m755 pkg/usr/share/emule
  cp -ra src/eMule"$pkgver"/* pkg/usr/share/emule
  find pkg/usr/share/emule -type d -exec chmod 755 "{}" \;
  find pkg/usr/share/emule -type f -exec chmod 644 "{}" \;

  install -d -m755 pkg/usr/bin
  install -m755 emule pkg/usr/bin 
}

Agora, nós fazemos nosso arquivo emule, que, de com o build, será copiado e tornado executável em /usr/bin.

#!/bin/bash
export WINEARCH=win32 WINEPREFIX="$HOME/.emule/wine"

if [ ! -d "$HOME"/.emule ] ; then
  mkdir -p "$HOME"/.emule/wine || exit 1
  #Cada usuário terá suas config, nós copiamos o arquivo padrão
  #já que o emule precisa escrevê-lo.
  cp -r /usr/share/emule/config "$HOME"/.emule || exit 1
  #Nós criamos links simbólicos para os arquivos que o emule precisa ler para funcionar
  ln -s /usr/share/emule/emule.exe "$HOME"/.emule/emule || exit 1
  ln -s -T /usr/share/emule/lang "$HOME"/.emule/lang || exit 1
  ln -s -T /usr/share/emule/webserver "$HOME"/.emule/webserver || exit 1
fi

wine "$HOME"/.emule/emule "$@"

Se você quiser ser mais preciso, você pode adicionar uma mensagem no arquivo .install dizendo ao usuário que ele deve desabilitar o histórico de busca, já que o wine bagunça aquele menu. Você pode até fornecer um arquivo de configuração padrão com as melhores configurações. E é isso ... execute $ makepkg, verifique a pasta do pacote para ter certeza e instale-o.

Gecko e Mono

A menos que você saiba com certeza que o software requer o navegador do tempo de execução do .NET (pacotes wine-gecko e wine-mono nos repositórios oficiais), os prompts padrão de instalação do wine para Gecko/Mono são indesejáveis.

Para desabilitar renderização HTML, suporte a bytecode e diálogos, você precisa usar um dlloverride em seu script. Para Gecko:

export WINEDLLOVERRIDES="mshtml="

Para Mono:

export WINEDLLOVERRIDES="mscoree="

Para ambos:

export WINEDLLOVERRIDES="mscoree,mshtml="

Você também pode desabilitá-los via winecfg: basta definir mscoree/mshtml para desabilitar.