A primeira parte do Makefile do port nomeia o port, descreve seu número da versão, e lista-os na categoria correta.
Você deve definir o PORTNAME ao nome da base de seu port, e PORTVERSION ao número da versão do port.
A variável PORTREVISION é uma monotonically aumentando o valor qual é redefinido a 0 com cada aumento da PORTVERSION (ex. cada vez que um oficial vendor release é feita), e adicionando ao nome do pacote se não-zero. PORTREVISION é aumentado cada vez que uma mudança é feita ao port do FreeBSD qual significantemente afeta o conteúdo ou estutura dos pacotes derivados.
Exemplos de quando PORTREVISION deve ser bumped:
Adição de patches para corrigir as vulnerabilidades de segurança, bugs, ou para adicionar novas funcionalidades ao port do FreeBSD.
Mudanças ao Makefile do port para abilitar ou desabilitar opções no tempo de compilação no pacote.
Mudanças na lista de empacotamento ou no tempo-da-instalação comportamento do pacote (ex. mudança ao script qual gera initial data para o pacote, como chaves ssh do host).
Version bump de umas dependencias da biblioteca compartilhada do port (neste caso, alguem tentando instalar o pacote antigo depois da instalado uma nova versão da dependencia falhará desde que ele procurar o antigo libfoo.x ao invés de libfoo.(x+1)).
Mudanças silenciosas ao distfile do port qual tem significantes diferenças funcionais, ex. mudanças ao distfile necessitando de uma correção ao distinfo com mudança não correspondente ao PORTVERSION, onde um diff -ru do antigo e novas versões mostra mudanças não-triviais ao código.
Exemplos de mudanças qual não necessitam uma PORTREVISION bump:
Mudanças de estilo ao esqueleto do port com mudanças não funcionais para que apareçam no pacote resultante.
Mudanças ao MASTER_SITES ou outras mudanças funcionais ao port qual não afeta o pacote resultante.
Patches triviais ao distfile como correção de typos, qual não são suficiente importante que usuários do pacote devem ir a problemas de upgrading.
Consertos de construção qual causa uma pacote torna-se compilável onde ele estava anteriormente falhando (as long as as mudanças não introduziram quaisquer mudanças funcionais em quaisquer outras platformas em qual o port foi construido anteriormente). Desde PORTREVISION reflita o conteúdo do pacote, se nenhum pacote foi anteriormente contrutivel então não há necessidade para aumentar PORTREVISION para marcar uma mudança.
Uma regra do thumb é perguntar a si mesmo se uma mudança committed a um port é algo qual alguem, algum local, beneficiará de ter (either because of an enhancement, conserto, ou by virtue que o novo pacote fincionará atualmente para eles). Se sim , o PORTREVISION deve ser bumped assim que ferramentas automatizadas (ex. pkg_version(1)) irá highlight o fato que um novo pacote está disponível.
De tempos em tempos um software vendor ou porter do FreeBSD fará algo silly e release uma versão de seus software qual está atualmente numericamente abaixo da versão anterior. Um exemplo disto é um port qual foi de foo-20000801 para foo-1.0 (o former será tratado incorretamente como uma versão mais nova desde 20000801 é um valor numericamente superior que 1).
Em situações como esta, a versão PORTEPOCH deve ser aumentada. Se PORTEPOCH é não-zero ele é adicionou ao nome do pacote como descrito na seção 0 acima. PORTEPOCH nunca é diminuido ou redefinido a zero, porque aquilo causaria comparação a um pacote de um anterior epoch a falhar (ex. o pacote não seria detectado como fora de data): o novo numero de versão (ex. 1.0,1 no exemplo acima) é ainda numericamente menor que a versão anterior (2000801), mas ferramentas automatizadas e encontradas para ser maior que o implica sufixo ,0 no pacote anterior.
É esperado que PORTEPOCH não será usado pela maioria dos ports, e que sensivel uso do PORTVERSION pode frequentemente pre-empt ele tornando-se necessário se uma futura release do software deve mudar a estrutura da versão. Entretanto, cuidado é necessário pelos porters do FreeBSD quando um vendor release é feito sem um número de versão oficial -- como um código ``snapshot'' release. A tentação é rotular a release com a data da release, qual causará problemas assim no exemplo acima quando uma nova release ``oficial'' é feita.
Por exemplo, se um snapshot release é feita na data 20000917, e a versão anterior do software foi a versão 1.2, a snapshot release deve ser dada a PORTVERSION de 1.2.20000917 ou similar, não 20000917, assim que a posterior release, diz 1.3, é ainda um valor numericamente superior.
O port gtkmumble, versão 0.10, é committed a coleção de ports:
PORTNAME= gtkmumble PORTVERSION= 0.10
PKGNAME torna-se gtkmumble-0.10.
Um buraco na segurança é descoberto qual necessita um patch local do FreeBSD. PORTREVISION é bumped de modo devido.
PORTNAME= gtkmumble PORTVERSION= 0.10 PORTREVISION= 1
PKGNAME torna-se gtkmumble-0.10_1
Uma nova versão é released pelo vendor, numerada 0.2 (it turns out the author actually intended 0.10 para atualmente mean 0.1.0, não ``que vem depois 0.9'' - oops, tão tarde agora). Desde o novo minor version 2 é numericamente abaixo que a versão anterior 10 o PORTEPOCH tem que ser bumped para forçar manualmente o novo pacote ser apagado como ``newer''. Desde que ele é um novo vendor release do código, PORTREVISION é redefinido a 0 (ou removido do Makefile).
PORTNAME= gtkmumble PORTVERSION= 0.2 PORTEPOCH= 1
PKGNAME torna-se gtkmumble-0.2,1
A próxima release é 0.3. Desde PORTEPOCH nunca diminuiu, as variáveis versão são agora:
PORTNAME= gtkmumble PORTVERSION= 0.3 PORTEPOCH= 1
PKGNAME torna-se gtkmumble-0.3,1
Nota: Se PORTEPOCH foi redefinido a 0 com esta melhoria, alguem que tinha instalado o pacote gtkmumble-0.10_1 não detectaria o pacote gtkmumble-0.3 como mais novo, desde 3 é ainda numericmente menor que 10.
Duas variáveis opcionais, PKGNAMEPREFIX e PKGNAMESUFFIX, são combinadas com PORTNAME e PORTVERSION ao form PKGNAME assim ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Certifique-se que este conforme ao nossa orientação para um bom nome de pacote. Em particular, voce não está permitido a usar um hífen (-) em PORTVERSION. Também, se o nome do pacote tem a language- ou o -compiled.specifics part, use PKGNAMEPREFIX e PKGNAMESUFFIX, respectivamentes. Não faça-os parte do PORTNAME.
Os seguintes são as convenções que voce deve seguir nomeando seus pacotes. Isto é ter nosso diretório de pacote fácil de scan, como há já muitos e muitos de pacotes e usuários are going to turn away se eles ferirem seus olhos!
O nome do pacote deve parecer como [language[_region]]-name[[-]compiled.specifics]-version.numbers.
O nome do pacote é definido como ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Certifique-se de definir as variáveis to conform a aquele fornato.
FreeBSD strives suportar a lingua nativa de seus usuários. A parte language- deve ser a abreviação de duas letras da lingua natural definida pelo ISO-639 se o port é especifico a uma certa lingua. Exemplos são ja para Japones, ru para Russo, vi para Vietnames, zh para Chines, ko para Koreano e de para Alemão.
Se o port é especifica a certa região within the language area, adicione as duas letras do código do país bem assim. Examples are en_US for US English and fr_CH para Swiss French.
A parte language- deve ser definida na variável PKGNAMEPREFIX.
A primeira letra da parte do nome deve ser lowercase. (O resto do nome pode conter letras capitais, assim use sua própria descrição quando voce está convertendo um nome de software que tem algumas letras capitais nela.) Há uma tradição de nameamento de módulos perl 5 por prepending p5- e convertendo o separador dois-pontos a um hífen; por exemplo, o módulo Data::Dumper torna-se p5-Data-Dumper. Se o software em questão tem números, hífens, ou underscores em seu nome, voce pode inclui-los bem assim (como kinput2).
Se o port pode ser construido com diferentes hardcoded defaults (normalmente parte do nome do diretório na familia do ports), a parte -compiled.specifics deve state the compiled-in defaults (o hífen é opcional). Exemplos são tamanho de papel e unidades de fontes.
A parte -compiled.specifics deve ser definido na variável PKGNAMESUFFIX.
A string da versão deve seguir um dash (-) e ser um separada-po-periodo lista de inteiros e single lowercase alphabetics. Em particular, não é permissivel ter um outro dash dentro da string da versão. A única execeção é a string pl (meaning ``patchlevel''), qual pode ser usada somente quando não há numeros de versão maior e menor no software. Se a versão do software tem strings como ``alpha'', ``beta'', ``rc'', ou ``pre'', pegue a primeira letra e coloque-a imediatamente depois de um periodo. Se a string da versão continua depois daqueles nomes, os numeros devem seguir o alfabeto somente sem um periodo extra entre eles.
A idéia é faze-lo mais fácil para sortir os ports considerando a string da versão. Em particular, certifique-se que o numero da versão dos componentes estão sempre delimitados por um periodo, e se a data é parte da string, use o formato yyyy.mm.dd , não dd.mm.yyyy ou a não-Y2K compliant yy.mm.dd format.
Aqui está alguns exemplos (reais) em como converter o nome assim chamado pelos autores do software a um nome de pacote suitable:
| Distribution Name | PKGNAMEPREFIX | PORTNAME | PKGNAMESUFFIX | PORTVERSION | Reason |
|---|---|---|---|---|---|
| mule-2.2.2 | (empty) | mule | (empty) | 2.2.2 | No changes required |
| XFree86-3.3.6 | (empty) | XFree86 | (empty) | 3.3.6 | No changes required |
| EmiClock-1.0.2 | (empty) | emiclock | (empty) | 1.0.2 | No uppercase names for single programs |
| rdist-1.3alpha | (empty) | rdist | (empty) | 1.3.a | No strings like alpha allowed |
| es-0.9-beta1 | (empty) | es | (empty) | 0.9.b1 | No strings like beta allowed |
| mailman-2.0rc3 | (empty) | mailman | (empty) | 2.0.r3 | No strings like rc allowed |
| v3.3beta021.src | (empty) | tiff | (empty) | 3.3 | What the heck was that anyway? |
| tvtwm | (empty) | tvtwm | (empty) | pl11 | Version string always required |
| piewm | (empty) | piewm | (empty) | 1.0 | Version string always required |
| xvgr-2.10pl1 | (empty) | xvgr | (empty) | 2.10.1 | pl allowed only when no major/minor version numbers |
| gawk-2.15.6 | ja- | gawk | (empty) | 2.15.6 | Japanese language version |
| psutils-1.13 | (empty) | psutils | -letter | 1.13 | Papersize hardcoded at package build time |
| pkfonts | (empty) | pkfonts | 300 | 1.0 | Package for 300dpi fonts |
Se há absolutamnete nenhum traço da informação da versão no fonte original e ele é unlikely original que o autor sempre liberará uma outra versão, só defina a string da versão a 1.0 (como o piewm exemplo acima). Caso contrário, pergunte o autor do original ou use a string da data (yyyy.mm.dd) as the version.