20.1. Adicionando um Novo Port |
- 20.1.1. Como eu adiciono um novo port?
- 20.1.2. Existe qualquer outra coisa que preciso saber quando adiciono um novo port?
|
20.1.1. | Como eu adiciono um novo port? |
| Primeiro, por favor leia a seção sobre cópias do repositório. A maneira mais fácil de adicionar um novo port é o script addport localizado no diretório ports/Tools/scripts . Ele adiciona um port do diretório especificado, determinando a categoria automaticamente a partir do Makefile do port. Também adiciona uma entrada à categoria do Makefile do port. Foi escrito por Michael Haro <mharo@FreeBSD.org> , Will Andrews <will@FreeBSD.org> e Renato Botelho <garga@FreeBSD.org> . Ao enviar perguntas sobre este script para a lista de discussão dos ports do FreeBSD, por favor também copie Chris Rees <crees@FreeBSD.org> , o mantenedor atual. |
20.1.2. | Existe qualquer outra coisa que preciso saber quando adiciono um novo port? |
| Verifique o port, de preferência para garantir que ele seja compilado e empacotado corretamente. Essa é a seqüência recomendada: # make install
# make package
# make deinstall
# pkg add package you built above
# make deinstall
# make reinstall
# make package
O Manual de Porters contém instruções mais detalhadas. Use o portlint(1) para verificar a sintaxe do port. Você não precisa necessariamente eliminar todos os avisos, mas certifique-se de ter corrigido os mais simples. Se o port veio de um remetente que não contribuiu para o projeto antes, adicione o nome dessa pessoa a seção Colaboradores Adicionais da Lista de Colaboradores do FreeBSD. Feche o PR se o port entrou como um PR. Para fechar um PR, mude o estado para Issue Resolved e a resolução como Fixed . |
20.2. Removendo um port existente |
- 20.2.1. Como faço para remover um port existente?
|
20.2.1. | Como faço para remover um port existente? |
| Primeiro, por favor leia a seção sobre cópias do repositório. Antes de remover o port, você deve verificar se não há outros ports dependendo dele. Alternativamente, você pode usar o script rmport , a partir de ports/Tools/scripts . Este roteiro foi escrito por Vasil Dimov <vd@FreeBSD.org> . Ao enviar perguntas sobre este script para a lista de discussão dos ports do FreeBSD, por favor também copie Chris Rees <crees@FreeBSD.org> , o mantenedor atual. |
20.3. Adicionando Novamente um Port que foi Removido |
- 20.3.1. Como faço para adicionar novamente um port que foi removido?
|
20.3.1. | Como faço para adicionar novamente um port que foi removido? |
| Isto é essencialmente o contrário de deletar um port. Importante: Não use svn add para adicionar o port. Siga esses passos. Se eles não estiverem claros, ou não estiverem funcionando, peça ajuda, não execute apenas o svn add para o port. Descubra quando o port foi removido. Use esta lista, ou procure o port em freshports e copie a última revisão viva do porto: % cd /usr/ports/category
% svn cp 'svn+ssh://repo.freebsd.org/ports/head/category /portname /@XXXXXX ' portname
Escolha a revisão que é justamente antes da remoção. Por exemplo, se a revisão em que foi removida for 269874 , use 269873 . Também é possível especificar uma data. Nesse caso, escolha uma data antes da remoção, mas depois do último commit para o port. % cd /usr/ports/category
% svn cp 'svn+ssh://repo.freebsd.org/ports/head/category /portname /@{YYYY-MM-DD }' portname
Faça as alterações necessárias para que o port funcione novamente. Se ele foi excluído porque os distfiles não estão mais disponíveis, seja voluntário para hospedar os distfiles ou encontre outra pessoa para fazê-lo. Se alguns arquivos foram adicionados, ou foram removidos durante o processo de ressurreição, use o svn add ou svn remove para certificar-se de que todos os arquivos no port serão aplicados no commit. Restaure o SUBDIR do port listado no diretório pai do Makefile , mantendo as entradas ordenadas. Exclua a entrada do port de ports/MOVED . Se o port tiver uma entrada em ports/LEGAL , a restaure. Execute o svn commit para estas mudanças, de preferência no primeiro passo.
Dica: O script addport mencionado em P & R 20.1, “Adicionando um Novo Port” agora detecta quando o port a ser adicionado existia anteriormente e tenta manipular todos automaticamente, exceto o ports/LEGAL . |
20.4. Cópias de Repositório |
- 20.4.1. Quando precisamos de uma cópia do repositório?
- 20.4.2. O que eu preciso fazer?
|
20.4.1. | Quando precisamos de uma cópia do repositório? |
| Quando você deseja adicionar um port relacionado a qualquer port que já esteja na árvore em um diretório separado, é necessário fazer uma cópia do repositório. Aqui relacionado significa que é uma versão diferente ou uma versão ligeiramente modificada. Exemplos são print/ghostscript* (versões diferentes) e x11-m/windowmaker* (versão somente inglesa e internacionalizada). Outro exemplo é quando um port é movido de um subdiretório para outro, ou quando o nome de um diretório deve ser alterado porque os autores renomearam seu software mesmo sendo um descendente de um port que já esta em uma árvore. |
20.4.2. | O que eu preciso fazer? |
| Com o Subversion, uma cópia do repo pode ser feita por qualquer committer: |
20.5. Freeze do Ports |
- 20.5.1. O que é um “ports freeze”?
|
20.5.1. | O que é um “ports freeze”? |
| Um “ports freeze” é um estado restrito em que a árvore de ports é colocada antes de uma release. Ele é usado para garantir uma qualidade superior para os pacotes enviados com um release. Geralmente dura algumas semanas. Durante esse tempo, problemas de build foram corrigidos e os pacotes de release foram criados. Esta prática não é mais usada, já que os pacotes para os releases são compilados a partir da branch trimestral stable. Para obter mais informações sobre como aplicar commits na branch trimestral, consulte P: 20.6.1. |
20.6. Branches Trimestrais |
- 20.6.1. Qual é o procedimento para solicitar autorização para aplicar um commit à branch trimestral?
- 20.6.2. Existe alguma alteração para a qual possa ser feito o commit sem aprovação?
- 20.6.3. Qual é o procedimento para aplicar os commits à branch trimestral?
|
20.6.1. | Qual é o procedimento para solicitar autorização para aplicar um commit à branch trimestral? |
| Ao fazer o commit, inclua o nome da branch na linha MFH: , por exemplo: MFH: 2014Q1 Ele notificará automaticamente a Equipe de Segurança do Ports <ports-secteam@FreeBSD.org> e a Equipe de Gerenciamento de Ports <portmgr@FreeBSD.org> . Eles então decidirão se o commit pode ser aplicado e responder com o procedimento. Se o commit já foi feito, envie um email para a Equipe de Segurança do Ports <ports-secteam@FreeBSD.org> e a Equipe de Gerenciamento de Ports <portmgr@FreeBSD.org> com o numero de revisão e uma pequena descrição de por que o commit precisa ser aplicado. Dica: Se o MFH está coberto por uma aprovação geral, explique o porque com algumas palavras na linha MFH , para que a equipe de revisão possa ignorar esse commit e economizar tempo. Por exemplo: MFH: 2014Q1 (runtime fix)
MFH: 2014Q1 (browser blanket) A lista de aprovações gerais está disponível em P: 20.6.2. |
20.6.2. | Existe alguma alteração para a qual possa ser feito o commit sem aprovação? |
| As seguintes aprovações implícitas para merge nas branches trimestrais estão em vigor: Nota: Essa aprovação geral também se aplica aos commits diretos para ports que foram removidos do head . Importante: Estas correções devem ser testadas na branch trimestral. Correções que não resultam em uma alteração no conteúdo do pacote resultante. Por exemplo: Correções de build, tempo de execução ou empacotamento, se a versão da branch trimestral estiver atualmente quebrada. Dependências ausentes (detectadas, vinculadas, mas não registradas, por meio de * _DEPENDS ). Correções de shebangs, remoção de bibliotecas e binários instalados e correções de plst. Backport de segurança e correções de confiabilidade que resultam apenas em um incremento no PORTREVISION e nenhuma alteração nos recursos habilitados. Por exemplo, adição de um patch que corrige um estouro de buffer. Alterações de versões secundárias que não fazem nada além de corrigir problemas de segurança ou relacionados a falhas. Adição/Conserto de CONFLICTS . Navegadores Web, plug-ins do navegador e suas dependências necessárias.
Importante: Commits que não são cobertos por essas aprovações implícitas sempre exigem aprovação explícita da Equipe de Segurança do Ports <ports-secteam@FreeBSD.org> ou da Equipe de Gerenciamento do Ports <portmgr@FreeBSD.org> . |
20.6.3. | Qual é o procedimento para aplicar os commits à branch trimestral? |
| Um script é fornecido para automatizar a mesclagem de um commit específico: ports/Tools/scripts/mfh . É usado da seguinte forma: % /usr/ports/Tools/scripts/mfh 380362
U 2015Q1
Checked out revision 380443.
A 2015Q1/security
Updating '2015Q1/security/rubygem-sshkit':
A 2015Q1/security/rubygem-sshkit
A 2015Q1/security/rubygem-sshkit/Makefile
A 2015Q1/security/rubygem-sshkit/distinfo
A 2015Q1/security/rubygem-sshkit/pkg-descr
Updated to revision 380443.
--- Merging r380362 into '2015Q1':
U 2015Q1/security/rubygem-sshkit/Makefile
U 2015Q1/security/rubygem-sshkit/distinfo
--- Recording mergeinfo for merge of r380362 into '2015Q1':
U 2015Q1
--- Recording mergeinfo for merge of r380362 into '2015Q1/security':
G 2015Q1/security
--- Eliding mergeinfo from '2015Q1/security':
U 2015Q1/security
--- Recording mergeinfo for merge of r380362 into '2015Q1/security/rubygem-sshkit':
G 2015Q1/security/rubygem-sshkit
--- Eliding mergeinfo from '2015Q1/security/rubygem-sshkit':
U 2015Q1/security/rubygem-sshkit
M 2015Q1
M 2015Q1/security/rubygem-sshkit/Makefile
M 2015Q1/security/rubygem-sshkit/distinfo
Index: 2015Q1/security/rubygem-sshkit/Makefile
===================================================================
--- 2015Q1/security/rubygem-sshkit/Makefile (revision 380443)
+++ 2015Q1/security/rubygem-sshkit/Makefile (working copy)
@@ -2,7 +2,7 @@
# $FreeBSD$
PORTNAME= sshkit
-PORTVERSION= 1.6.1
+PORTVERSION= 1.7.0
CATEGORIES= security rubygems
MASTER_SITES= RG
Index: 2015Q1/security/rubygem-sshkit/distinfo
===================================================================
--- 2015Q1/security/rubygem-sshkit/distinfo (revision 380443)
+++ 2015Q1/security/rubygem-sshkit/distinfo (working copy)
@@ -1,2 +1,2 @@
-SHA256 (rubygem/sshkit-1.6.1.gem) = 8ca67e46bb4ea50fdb0553cda77552f3e41b17a5aa919877d93875dfa22c03a7
-SIZE (rubygem/sshkit-1.6.1.gem) = 135680
+SHA256 (rubygem/sshkit-1.7.0.gem) = 90effd1813363bae7355f4a45ebc8335a8ca74acc8d0933ba6ee6d40f281a2cf
+SIZE (rubygem/sshkit-1.7.0.gem) = 136192
Index: 2015Q1
===================================================================
--- 2015Q1 (revision 380443)
+++ 2015Q1 (working copy)
Property changes on: 2015Q1
___________________________________________________________________
Modified: svn:mergeinfo
Merged /head:r380362
Do you want to commit? (no = start a shell) [y/n]
Nesse ponto, o script abrirá um shell para você consertar as coisas ou abrirá o editor de texto com a mensagem de commit preparada e, em seguida, irá aplicar o commit. O script assume que você pode se conectar ao repo.FreeBSD.org com o SSH diretamente, então se o seu nome de login local for diferente da sua conta no cluster do FreeBSD, você precisa de algumas linhas em seu ~/.ssh/config : Host *.freebsd.org
User freebsd-login Dica: O script também pode aplicar mais de uma revisão por vez. Se houver outras atualizações no port desde que a branch foi criada e que não foram aplicadas porque não estavam relacionadas à segurança. Adicione as diferentes revisões na ordem em que foram feitos seus commits na linha de comando mfh . A nova mensagem de log de commit conterá as mensagens de log combinadas de todos os commits originais. Estas mensagens devem ser editadas para mostrar o que realmente está sendo feito com o novo commit. % /usr/ports/Tools/scripts/mfh r407208 r407713 r407722 r408567 r408943 r410728
Nota: O script mfh também pode ter um primeiro argumento opcional, a branch onde a aplicação está sendo feita. Apenas a última branch trimestral é suportada, portanto, especificar a branch é desencorajado. Por segurança, o script emitirá um aviso se a branch trimestral não for a mais recente: % /usr/ports/Tools/scripts/mfh 2016Q1 r407208 r407713
/!\ The latest branch is 2016Q2, do you really want to commit to 2016Q1? [y/n]
|
20.7. Criando uma Nova Categoria |
- 20.7.1. Qual é o procedimento para criar uma nova categoria?
- 20.7.2. O que preciso fazer para implementar uma nova categoria física?
- 20.7.3. O que preciso fazer para implementar uma nova categoria virtual?
|
20.7.1. | Qual é o procedimento para criar uma nova categoria? |
| Por favor, veja Propondo uma nova categoria no FreeBSD Porter's Handbook. Uma vez que o procedimento tenha sido seguido e o PR tenha sido atribuído à Equipe de Gerenciamento de Ports <portmgr@FreeBSD.org> , é decisão deles aprová-lo ou não. Se eles fizerem isso, é sua responsabilidade: Executar todos os passos necessários. (Isso só se aplica a categorias físicas.) Atualizar a definição de VALID_CATEGORIES em ports/Mk/bsd.port.mk . Atribua o PR de volta para você.
|
20.7.2. | O que preciso fazer para implementar uma nova categoria física? |
| Atualize o Makefile de cada port movido. Não conecte a nova categoria ao build ainda. Para fazer isso, você precisará: Altere as CATEGORIES do port (esse foi o ponto do exercício, lembra?) A nova categoria está listada primeiro. Isso ajudará a garantir que o PKGORIGIN esteja correto. Execute um make describe . Como o make index de nível superior que você executará em poucas etapas é uma iteração do make describe sobre a hierarquia de ports inteira, detectar erros aqui irá salvar você de ter que voltar a executar esse passo mais tarde. Se você quiser ser realmente meticuloso, agora pode ser um bom momento para executar o portlint(1).
Verifique se os PKGORIGIN s estão corretos. O sistema de ports usa a entrada CATEGORIES de cada port para criar seu PKGORIGIN , que é usado para conectar pacotes instalados ao diretório de port do qual eles foram compilados. Se esta entrada estiver errada, ferramentas de port comuns como pkg_version(1) e o portupgrade(1) irão falhar. Para fazer isso, use a ferramenta chkorigin.sh : env PORTSDIR=/path/to/ports sh -e /path/to/ports /Tools/scripts/chkorigin.sh . Isso irá verificar todos os ports na árvore de ports, mesmo aqueles que não estão conectados à compilação, para que você possa executá-las diretamente após a operação de mudança. Dica: não esqueça de olhar para o PKGORIGIN s de qualquer port slave dos ports que você acabou de mudar! Em seu próprio sistema local, teste as alterações propostas: primeiro, comente as entradas SUBDIR nos Makefile s das 'categorias' antigas do port; em seguida, habilite a compilação da nova categoria em ports/Makefile . Execute make checksubdirs nos diretórios de categoria afetados para verificar as entradas SUBDIR . Em seguida, no diretório ports/ , execute make index . Isso pode levar mais de 40 minutos em sistemas modernos; no entanto, é um passo necessário para evitar problemas para outras pessoas. Uma vez feito isso, você pode fazer o commit do ports/Makefile atualizado para conectar a nova categoria à compilação e também fazer o commit das alterações do Makefile para a categoria ou categorias antigas. Adicione as entradas apropriadas no ports/MOVED . Atualize a documentação modificando: a lista de categorias no FreeBSD Porter's Handbook doc/en_US.ISO8859-1/htdocs/ports . Observe que agora eles são exibidos por subgrupos, conforme especificado em doc/en_US.ISO8859-1/htdocs/ports/categories.descriptions .
(Nota: estes estão nos docs, não nos ports, repositório). Se você não é um doc committer, você precisará enviar um PR para isso. Apenas quando todas as opções acima tiverem sido concluídas, e ninguém mais estiver relatando problemas com os novos ports, os ports antigos devem ser excluídos de seus locais anteriores no repositório.
Não é necessário atualizar manualmente as páginas web dos ports para refletir a nova categoria. Isso será feito automaticamente através da alteração em en_US.ISO8859-1/htdocs/ports/categories e o rebuild automático do INDEX . |
20.7.3. | O que preciso fazer para implementar uma nova categoria virtual? |
| Isso é muito mais simples que uma categoria física. Apenas algumas modificações são necessárias: |
20.8. Perguntas Diversas |
- 20.8.1. Existe alguma alteração para a qual possa ser feito o commit sem a aprovação do mantenedor?
- 20.8.2. Como sei se meu port está sendo compilado corretamente ou não?
- 20.8.3. Eu adicionei um novo port. Preciso adicioná-lo ao INDEX?
- 20.8.4. Existem outros arquivos que não tenho permissão para tocar?
- 20.8.5. Qual é o procedimento adequado para atualizar o checksum de um distfile de um port quando o arquivo é alterado sem uma alteração de versão?
- 20.8.6. Como uma build de teste experimental da árvore de ports (exp-run) pode ser solicitada?
|
20.8.1. | Existe alguma alteração para a qual possa ser feito o commit sem a aprovação do mantenedor? |
| A aprovação implícita para a maioria dos ports se aplica a estes tipos de correções: A maioria das alterações de infraestrutura para um port (isso é, modernizar, sem alterar funcionalidades). Por exemplo, a aprovação implícita inclui a conversão de novas macros USES , ativar verbosidade de compilação e alterações para novas sintaxes de sistema do ports. Trivialidades e correções testadas de compilação e execução.
Importante: Exceções para isso são qualquer coisa que seja mantido pela Equipe de Gerenciamento do Ports <portmgr@FreeBSD.org> ou pelo Time de Oficiais de Segurança <security-officer@FreeBSD.org> . Nenhum commit não autorizado pode ser feito em ports mantidos por esses grupos. |
20.8.2. | Como sei se meu port está sendo compilado corretamente ou não? |
| Os pacotes são criados várias vezes por semana. Se um port falhar, o mantenedor receberá um email de pkg-fallout@FreeBSD.org . Relatórios para todas as compilações de pacotes (oficiais, experimentais e não regressivos) são agregados em pkg-status.FreeBSD.org. |
20.8.3. | Eu adicionei um novo port. Preciso adicioná-lo ao INDEX ? |
| Não. O arquivo pode ser gerado executando make index , ou uma versão pré-gerada pode ser baixada com o comando make fetchindex . |
20.8.4. | Existem outros arquivos que não tenho permissão para tocar? |
| Qualquer arquivo diretamente sob ports/ , ou qualquer arquivo sob um subdiretório que comece com uma letra maiúscula (Mk/ , Tools/ , etc.) . Em particular, a Equipe de Gerenciamento de Ports <portmgr@FreeBSD.org> protege muito o ports/Mk/bsd.port*.mk , portanto, não faça alterações nesses arquivos, a menos que você queira enfrentar a sua ira. |
20.8.5. | Qual é o procedimento adequado para atualizar o checksum de um distfile de um port quando o arquivo é alterado sem uma alteração de versão? |
| Quando o checksum de um arquivo de distribuição é atualizado devido ao autor atualizar o arquivo sem alterar a revisão do port, a mensagem de commit inclui um resumo dos diffs relevantes entre o distfile original e novo para garantir que o distfile não tenha sido corrompido ou alterado de maneira mal-intencionada . Se a versão atual do port estiver na árvore de ports por um tempo, uma cópia do antigo distfile estará normalmente disponível nos servidores ftp; caso contrário, o autor ou mantenedor deve ser contatado para descobrir por que o distfile foi alterado. |
20.8.6. | Como uma build de teste experimental da árvore de ports (exp-run) pode ser solicitada? |
| Um exp-run deve ser realizado antes que seja feito o commit de patches com um impacto significativo nos ports. O patch pode ser contra a árvore de ports ou o sistema base. A build completa do pacote será feita com as correções fornecidas pelo remetente, e o remetente deverá corrigir os problemas detectados (fallout) antes de fazer o commit. Vá para a nova página de PR do Bugzilla. Selecione o produto ao qual seu patch se aplica. Preencha o relatório de erros normalmente. Lembre-se de anexar o patch. Se no topo existir “Show Advanced Fields” clique sobre ele. Agora, ele dirá “Hide Advanced Fields”. Muitos novos campos estarão disponíveis. Se a pagina já diz “Hide Advanced Fields”, não precisa fazer nada. Na seção “Flags”, defina o “exp-run” para ? . Quanto a todos os outros campos, passar o mouse sobre qualquer campo mostrará mais detalhes. Envie. Aguarde a build ser executada. A Equipe de Gerenciamento do Ports <portmgr@FreeBSD.org> responderá com uma possível fallout. Dependendo do fallout:
|