GNOME package guidelines (Português)

Status de tradução: Esse artigo é uma tradução de GNOME package guidelines. Data da última tradução: 2020-06-15. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Diretrizes de pacotes do Arch

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Fonte – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – VCS – Web – Wine

Os pacotes do GNOME no Arch Linux segue, um certo esquema.

URL fonte

Esse tópico contém as URLs fonte mais comumente usadas pelos pacotes GNOME nos repositórios oficiais e no AUR. Para exemplos, pesquise por pacotes GNOME nos repositórios oficiais[1] e no AUR[2]

Usando tarball de lançamento

Ao baixar um tarball de lançamento, você pode obtê-lo de https://download.gnome.org usando o seguinte vetor fonte:

source=("https://download.gnome.org/sources/$pkgname/${pkgver%.*}/$pkgname-$pkgver.tar.xz")

sendo que ${pkgver%.*} retorna a versão de pacote maior.menor, removendo o sufixo do pkgver (que é a versão de pacote micro). Por exemplo, se pkgver=3.28.0, então ${pkgver%.*} retornaria 3.28.

Usando um commit do repositório Git

Uma outra prática comum é usar como fonte um commit específico de um repositório git de código fonte do software GNOME. Isso não se classifica como pacote VCS porque o recurso do Pacman de definir um commit específico[3] faz o PKGBUILD não seguir os últimos commits de desenvolvimento nem atualizar o campo pkgver, em vez disso, usando o fonte do hash de commit especificado.

Veja um modelo abaixo:

PKGBUILD

makedepends=(git)
commit=hash_de_um_commit 
source=("git+https://gitlab.gnome.org/GNOME/$pkgname.git#commit=$_commit")
md5sums=('SKIP')

pkgver() {
  cd $pkgname
  git describe --tags | sed 's/-/+/g'
}

Substitua hash_de_um_commit com a hash do commit Git desejado.

Note que já que o fonte é baixado com git, então git deve estar no makedepends e somas de verificação devem ser definidas para SKIP, assim como ocorreria com qualquer outro pacote VCS. O uso da função pkgver() é altamente recomendado, de forma que defina o pkgver adequadamente para o hash de commit fornecido.

Note: GNOME já usou https://git.gnome.org, mas então migrou para o https://gitlab.gnome.org [4]. Links antigos devem ser redirecionados automaticamente para o novo domínio gitlab.gnome.org, mas pode ser interessante atualizar manualmente a URL do seu fonte.

Compilando com meson

Muitos softwares do GNOME migraram o sistema de compilação para o Meson, consequentemente descartando o suporte a GNU Autotools. Isso significa que você usará ./configure e make neste caso.

Para compilar usando o Meson, adicione o pacote meson para makedepends e execute seu comando meson, incluindo opcionalmente todas as opções desejadas suportadas pelo software alvo. O pacote ninja também será usado neste sistema de compilação, mas é uma dependência do meson, então você não precisa incluí-lo no vetor makedepends.

As funções build(), check() e package() devem ser parecer com:

PKGBUILD

makedepends=(meson)

build() {
  meson --prefix /usr --buildtype=plain fonte build
  ninja -C build
}

check() {
  ninja -C build check
}

package() {
  DESTDIR="$pkgdir" ninja -C build install
}

sendo que

fonte é o diretório contendo o código-fonte extraído como, por exemplo, $pkgname ou $pkgname-$pkgver; e
build é o diretório que conterá os arquivos binários a serem instalados. Normalmente o nome de diretório "build" é usado, então você pode querer mantê-lo para padronização, mas você pode renomeá-lo para o que mais lhe agradar.

Nota:

Alguns softwares não suportam a chamada de meson de fora do diretório raiz do código-fonte. Se este for o seu caso, adapte o bloco de código acima simplesmente adicionando cd fonte ao início das três funções acima, e também alterando a linha de comando meson acima para meson . build.
Se o software não tiver regras de teste definidas (caso em que o bloco de código acima falharia para construir o pacote), remova/comente a toda a função check().

Dica: Para alternar uma opção de compilação no meson, anexe os sinalizadores -Dopção=valor à linha de comando do meson, em que opção é uma opção suportada para o software de destino que você está compilando, e valor é um valor válido para a opção fornecida. Então, por exemplo, se o software tem uma opção gtk_doc como false por padrão e você quer habilitá-la, acrescente -Dgtk_doc=true à linha de comando do meson. Leia os arquivos meson.build e meson_options.txt no diretório-raiz do código-fonte para encontrar as opções disponíveis.

GConf schemas

Alguns pacotes do GNOME instalam schemas do GConf, apesar de muitos outros já terem migrados para GSettings. Aqueles pacotes devem depender de gconf^AUR.

Schemas do Gconf são instalados na base de dados GConf do sistema, que deve ser evitado. Alguns pacotes fornecem uma opção --disable-schemas-install para o ./configure, que dificilmente funciona. Porém, gconftool-2 tem uma variável chamada GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL a qual você pode definir para dizer ao gconftool-2 para não atualizar qualquer base de dados.

Ao criar pacotes que instalam arquivos schemas de GConf, use

make GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 DESTDIR=${pkgdir} install

para a etapa de instalação do pacote no PKGBUILD.

Não chame gconfpkg no arquivo .install, pois schemas do GConf são automaticamente instalados/removidos (na instalação/remoção de um pacote GNOME) via hooks do pacman desde o gconf^AUR=3.2.6-4

GSettings schemas

Os schemas de Gconf foram migrados para schemas do GSettings, então muitos aplicativos pode ser encontrados usando esse novo arquivo de schema. GSettings usa o dconf como backend, então todos os pacotes que contêm schemas de GSettings exigem dconf como dependência. Quando um novo schema de GSettings é instalado no sistema, a base de dados do GSettings tem que ser recompilada, mas não durante o empacotamento.

Para evitar recompilação da base de dados do GSettings no empacotamento, use a opção --disable-schemas-compile para o ./configure.

Não chame glib-compile-schemas no arquivo .install, pois as bases de dados de schemas do GSettings são recompilados automaticamente via hooks do pacman desde glib2=2.48.0-2.

Documentação do Scrollkeeper

A partir do GNOME 2.20, não há mais necessidade de lidar com scrollkeeper, pois rarian^AUR lê seus arquivos OMF diretamente. Scrollkeeper-update é um link dos dias atuais. A única coisa que é necessário agora é acrescentar gnome-doc-utils^AUR>=0.11.2 ao vetor makedepends.

Ele pode ser desabilitado usando a opção --disable-scrollkeeper no ./configure.

Cache de ícones do GTK

Alguns ícones de instalação de pacotes no tema do ícone do hicolor.

Não chame gtk-update-icon-cache no arquivo .install, pois o cache de ícone é atualizado via hooks do pacman desde gtk-update-icon-cache=3.20.3-2. Tais pacotes não devem depender de gtk-update-icon-cache, pois qualquer aplicativo que faz uso de caches de ícones gtk vai instalar o pacote com o hook e fará uma atualização de banco de dados completa e retroativa.

Arquivos .desktop

Muitos pacotes instalam arquivos .desktop compatíveis com Freedesktop.org e registram entradas tipo MIME neles.

Não chame update-desktop-database no arquivo .install, pois a base de dados é atualizada automaticamente via hooks do pacman desde desktop-file-utils=0.22-2. Tais pacotes não devem depender de desktop-file-utils, pois qualquer desktop que faz uso de arquivos de desktop vai instalar o pacote com o hook e fará uma atualização de banco de dados completa e retroativa.

Arquivos .install

Anteriormente, a maioria dos pacotes GNOME tinham um arquivo .install chamando comandos como glib-compile-schemas, gtk-update-icon-cache e update-desktop-database para instalar/atualizar cache local ou base de dados. Isso está obsoleto desde o pacman 5.0, que trouxe a implementação de hooks que chamam aqueles comandos automaticamente ao instalar o pacote.

Para evitar ser chamado duas vezes, os comandos supramencionados devem ser removidos do arquivo .install.