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]
[
link inativo
2025-03-15 ⓘ]
. 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
-D
opçã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.