VCS package guidelines (Português)

A partir do pacman 4.1, os fontes VCS devem ser especificados no vetor e será tratado como qualquer outro fonte. vai realizar clone/checkout/branch do repositório para (mesmo que se não definido no makepkg.conf(5)) e vai copiá-lo para (em uma forma específica para cada VCS). O repositório local é deixado intocado, portanto passando a ser desnecessário ter um diretório .

O formato geral de um vetor de VCS é:

source=('[pasta::][vcs+]url[#fragmento]')

• pasta (opcional) é usada para alterar o nome do repositório padrão para algo mais relevante (p. ex., do que ) ou para preservar os fontes anteriores.
• é necessário para URLs que não refletem o tipo VCS, p. ex., .
• é o URL para o repositório distante ou local.
• (opcional) é necessário para fazer pull um branch ou commit específico. Veja para mais informações nos fragmentos disponíveis para cada VCS.

Um exemplo de vetor fonte de Git:

source=('nome_projeto::git+https://url_projeto#branch=ramo_projeto')

O autoincremento de pkgver agora é alcançado através de uma função pkgver() dedicada. Isso permite um melhor controle sobre o pkgver, e os mantenedores devem favorecer um pkgver que faça sentido. Para usar pkgver(), você ainda precisa declarar a variável pkgver com o valor mais recente. O makepkg irá invocar a função pkgver() e atualizar a variável pkgver de acordo.

Recomenda-se ter o seguinte formato de versão: LANÇAMENTO.rREVISÃO onde REVISÃO é um número monotonicamente crescente que identifica exclusivamente a árvore de fonte (revisões VCS fazem isso). Se não houver lançamentos públicos e nenhuma tag de repositório, o zero pode ser usado como um número de release ou você pode descartar LANÇAMENTO e usar o número da versão que se parece com rREVISÃO. Se houver lançamentos públicos, mas o repo não tiver tags, o desenvolvedor deve obter a versão de lançamento de alguma forma, por exemplo, analisando os arquivos do projeto.

O delimitador do número de revisão ("r" logo antes da REVISÃO) é importante. Esse delimitador permite evitar problemas caso o upstream decida fazer seu primeiro lançamento ou use versões com diferentes números de componentes. Por exemplo, se na revisão "455" o upstream decidir lançar a versão 0.1, o delimitador de revisão preservará a monotonicidade da versão - . Sem o delimitador, a monotonicidade falha - .

Veja PKGBUILD-vcs.proto para exemplos genéricos mostrando a saúde visada.

Usando a tag anotada mais recente alcançável do último commit:

Usando a tag não anotada mais recente alcançável do último commit:

No caso, se a tag git não contém traços, então pode-se usar uma expressão sed mais simples, como .

Se a tag contiver um prefixo, como ou o nome do projeto, ele deverá ser cortado:

pkgver() {
  cd "$pkgname"
  # cortando o prefixo "foo-" apresentado na tag do git
  git describe --long | sed 's/^foo-//;s/\([^-]*-g\)/r\1/;s/-/./g'
}

6.1.r3.gd77e105

Se não houver tags, use o número de revisões desde o início do histórico:

Versão e somente o commit/número da revisão (SHA1 omitido; no entanto, sem uma referência rápida SHA1 de uma revisão exata, ela é perdida se não estiver atento ao controle de versão):

git describe --long | sed -r 's/-([0-9,a-g,A-G]{7}.*)//' | sed 's/-/./g'

Ambos os métodos também podem ser combinados, para suportar repositórios que iniciam sem uma tag, mas são marcados mais tarde (use um "bashismo"):

Caso nenhum pkgver satisfatório possa ser extraído do repositório, a data atual pode ser usada:

Embora não identifique o estado da árvore de fonte de forma exclusiva, então evite-o, se possível.

Submódulos de Git são um pouco complicados de se fazer. A ideia é adicionar as URLs dos submódulos diretamente ao vetor de fontes e, em seguida, referenciá-las durante o prepare(). Isso poderia ser assim: