GNOME package guidelines (Português)
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 e no AUR
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 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.
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:
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.
GConf schemas
Alguns pacotes do GNOME instalam schemas do GConf, apesar de muitos outros já terem migrados para GSettings. Aqueles pacotes devem depender de .
Schemas do Gconf são instalados na base de dados GConf do sistema, que deve ser evitado.
Alguns pacotes fornecem uma opção 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 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 =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 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 para o ./configure.
Não chame no arquivo .install, pois as bases de dados de schemas do GSettings são recompilados automaticamente via hooks do pacman desde =2.48.0-2.
Documentação do Scrollkeeper
A partir do GNOME 2.20, não há mais necessidade de lidar com scrollkeeper, pois lê seus arquivos OMF diretamente. Scrollkeeper-update é um link dos dias atuais. A única coisa que é necessário agora é acrescentar >=0.11.2 ao vetor makedepends.
Ele pode ser desabilitado usando a opção 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 compatíveis com Freedesktop.org e registram entradas tipo MIME neles.
Não chame no arquivo .install, pois a base de dados é atualizada automaticamente via hooks do pacman desde =0.22-2. Tais pacotes não devem depender de , 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 , gtk-update-icon-cache e 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.