Index: head/pt_BR.ISO8859-1/books/porters-handbook/book.xml =================================================================== --- head/pt_BR.ISO8859-1/books/porters-handbook/book.xml (revision 53157) +++ head/pt_BR.ISO8859-1/books/porters-handbook/book.xml (revision 53158) @@ -1,24735 +1,25377 @@ ]> FreeBSD Porter's Handbook Projeto de Documentação do FreeBSD - $FreeBSD$ + $FreeBSD$ 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 Projeto de Documentação do FreeBSD Copyright Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: Redistributions of source code (XML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. FreeBSD is a registered trademark of the FreeBSD Foundation. UNIX is a registered trademark of The Open Group in the United States and other countries. Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. - $FreeBSD$ + $FreeBSD$ Introdução A Coleção de Ports do FreeBSD é a maneira como quase todo mundo instala aplicativos ("ports") no FreeBSD. Como tudo no FreeBSD, é principalmente um esforço voluntário. É importante ter isso em mente ao ler este documento. No FreeBSD, qualquer um pode enviar um novo port ou ser voluntário para manter um port que esteja sem mantenedor. Nenhum privilégio de commit é necessário. Criando um Novo Port Interessado em fazer um novo port ou atualizar os ports existentes? Ótimo! O que segue são algumas instruções para criar um novo port para o FreeBSD. Para atualizar um port existente, leia este documento e depois leia o . Quando este documento não for suficientemente detalhado, consulte /usr/ports/Mk/bsd.port.mk, que é incluído por todos os Makefiles dos ports. Mesmo aqueles que não estão hackeando os Makefiles diariamente podem ganhar muito conhecimento com isso. Além disso, perguntas específicas podem ser enviadas à Lista de discussão do ports do FreeBSD. Apenas uma fração das variáveis ​​(VAR) que podem ser sobrepostas são mencionados neste documento. A maioria (se não todas) estão documentadas no início do /usr/ports/Mk/bsd.port.mk; as outras provavelmente deveriam estar também. Observe que esse arquivo usa uma configuração de tabulação não padrão: O Emacs e o Vim irão reconhecer a configuração ao carregar o arquivo. Ambos vi1 e ex1 podem ser configurados para usar o valor correto digitando :set tabstop=4 uma vez que o arquivo foi carregado. Procurando algo fácil para começar? Dê uma olhada na lista de ports desejados e veja se você pode trabalhar em um (ou mais de um). Port Rápido Esta seção descreve como criar rapidamente um novo port. Para aplicativos em que esse método rápido não for adequado, o processo Slow Porting está descrito no . Primeiro, obtenha o tarball original e coloque-o em DISTDIR, que por padrão é o diretório /usr/ports/distfiles. Estas etapas assumem que o software foi compilado de forma simples (out-of-the-box). Em outras palavras, não foi necessária absolutamente nenhuma mudança para o aplicativo funcionar em um sistema FreeBSD. Se alguma coisa teve que ser alterada, por favor consulte o . Recomenda-se definir a variável DEVELOPER do make1 em /etc/make.conf antes de começar o trabalho com os ports. # echo DEVELOPER=yes >> /etc/make.conf Esta configuração habilita o modo de desenvolvedor que exibe avisos sobre a descontinuidade de comandos e ativa algumas verificações de qualidade adicionais nas execuções do comando make. Escrevendo o <filename>Makefile</filename> O Makefile mínimo seria algo assim: # $FreeBSD$ PORTNAME= oneko DISTVERSION= 1.1b CATEGORIES= games MASTER_SITES= ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/ MAINTAINER= youremail@example.com COMMENT= Cat chasing a mouse all over the screen .include <bsd.port.mk> Em alguns casos, o Makefile de um port existente pode conter linhas adicionais no cabeçalho, como o nome do port e a data em que foi criado. Esta informação adicional foi declarada obsoleta e está sendo eliminada. Tente entender o exemplo. Não se preocupe com o conteúdo da linha $FreeBSD$, ela será preenchida automaticamente pelo Subversion quando o port for importado para nossa árvore de ports principais. Um exemplo mais detalhado é mostrado na seção exemplo de Makefile. Escrevendo os Arquivos de Descrição Existem dois arquivos de descrição que são necessários para qualquer port, independente deles estarem empacotados ou não. Eles são o pkg-descr e o pkg-plist. Seus prefixos pkg- distingue-os de outros arquivos. <filename>pkg-descr</filename> Esta é uma descrição mais longa do port. Um ou alguns parágrafos que explicam o que o port faz é suficiente. Isto não é um manual ou uma descrição detalhada sobre como usar ou compilar o port! Por favor, tenha cuidado ao copiar do README ou manpage . Muitas vezes, eles não são uma descrição concisa do port ou estão em um formato estranho. Por exemplo, as páginas de manual têm espaçamento justificado, o que parece particularmente ruim com fontes monoespaçadas. Por outro lado, o conteúdo de pkg-descr deve ser mais longo que a linha COMMENT do Makefile. Ele deve explicar com mais profundidade o que é o port. Um pkg-descr bem escrito descreve o port completamente o suficiente para que os usuários não precisem consultar a documentação ou visitar o site para entender o que o software faz, como ele pode ser útil ou quais recursos particularmente legais ​​ele possui. A menção de certos requisitos, como um kit de ferramentas gráfico, dependências pesadas, ambiente de runtime ou linguagens de implementação, ajuda os usuários a decidir se este port funcionará para eles. Inclua uma URL para a página Web oficial. Prefixe um dos sites (escolha o mais comum) com WWW: (seguido por um único espaço) para que as ferramentas automatizadas funcionem corretamente. Se a URI é a raiz do site ou diretório, ele deve ser terminado com uma barra. Se a página web listada para um port não estiver disponível, tente pesquisar na Internet primeiro para ver se o site oficial foi movido, foi renomeado ou se está hospedado em outro lugar. Este exemplo mostra como parece o pkg-descr: This is a port of oneko, in which a cat chases a poor mouse all over the screen. : (etc.) WWW: http://www.oneko.org/ <filename>pkg-plist</filename> Este arquivo lista todos os arquivos instalados pelo port. Ele também é chamado de packing list (lista de empacotamento) porque o pacote é gerado empacotando os arquivos listados aqui. Os pathnames são relativos ao prefixo de instalação (geralmente /usr/local). Aqui está um pequeno exemplo: bin/oneko man/man1/oneko.1.gz lib/X11/app-defaults/Oneko lib/X11/oneko/cat1.xpm lib/X11/oneko/cat2.xpm lib/X11/oneko/mouse.xpm Consulte a manpage do pkg-create8 para detalhes sobre a lista de empacotamento. É recomendado manter todos os nomes de arquivos neste arquivo classificados em ordem alfabética. Isso tornará muito mais fácil verificar as alterações ao atualizar o port. Criar uma lista de packing manualmente pode ser uma tarefa muito tediosa. Se o port instalar um grande número de arquivos, criar a lista de empacotamento automaticamente pode economizar tempo. Há apenas um caso em que o pkg-plist pode ser omitido de um port. Se o port instalar apenas alguns arquivos, liste-os em PLIST_FILES, dentro do Makefile do port. Por exemplo, poderíamos passar sem o pkg-plist no port oneko acima, adicionando estas linhas para no Makefile: PLIST_FILES= bin/oneko \ man/man1/oneko.1.gz \ lib/X11/app-defaults/Oneko \ lib/X11/oneko/cat1.xpm \ lib/X11/oneko/cat2.xpm \ lib/X11/oneko/mouse.xpm Uso de PLIST_FILES não deve ser abusado. Ao procurar pela origem de um arquivo, as pessoas geralmente tentam usar o grep através do pkg-plist nos arquivos na árvore de ports. Listar os arquivos na variável PLIST_FILES dentro do Makefile torna esta busca mais difícil. Se um port precisar criar um diretório vazio, ou criar diretórios fora do ${PREFIX} durante a instalação, consulte para maiores informações. Como PLIST_FILES é uma variavel do make1, qualquer entrada com espaços deve ser envolvida por aspas. Por exemplo, se estiver usando palavras-chave descritas em pkg-create8 e na , a entrada deve ser citada. PLIST_FILES= "@sample ${ETCDIR}/oneko.conf.sample" Mais tarde vamos ver como o pkg-plist e a PLIST_FILES podem ser utilizados para executar tarefas mais sofisticadas. Criando o Arquivo Checksum Apenas digite make makesum. O framework do ports irá gerar automaticamente o distinfo. Não tente gerar o arquivo manualmente. Testando o Port Certifique-se de que as regras do port façam exatamente o que é desejado, incluindo o empacotamento do port. Estes são os pontos importantes a serem verificados: pkg-plist não contém nada não instalado pelo port. pkg-plist contém tudo o que é instalado pelo port. O port pode ser instalado usando o target install. Isso verifica se o script de instalação está funcionando corretamente. O port pode ser desinstalado adequadamente usando o target deinstall. Isso verifica se o script de desinstalação funciona corretamente. O port só tem acesso aos recursos de rede durante a fase target fetch. Isto é importante para os construtores de pacotes, tais como o ports-mgmt/poudriere. Certifique-se de que o comando make package pode ser executado como um usuário normal (ou seja, não como root). Se isso falhar, talvez seja necessário corrigir o software. Veja a e também a . Ordem Recomendada de Teste make stage make stage-qa make package make install make deinstall make package (como usuário) Certifique-se de que nenhum aviso é exibido em nenhum dos estágios. Testes automatizados completos podem ser feitos com o ports-mgmt/poudriere da coleção do Ports, veja a para maiores informações. Ele mantém jails onde todas as etapas mostradas acima podem ser testadas sem afetar o estado do sistema host. Verificando o Port com <command>portlint</command> Por favor, use o portlint para ver se o port está de acordo com as nossas diretrizes. O programa ports-mgmt/portlint faz parte da coleção de ports. Em particular, ele verifica se o Makefile está correto e se o pacote está nomeado apropriadamente. Não siga cegamente a saída do portlint. Ela é uma ferramenta de lint estática e às vezes comete erros. Enviando o Novo Port Antes de enviar o novo port, leia a seção sobre o que fazer e o que não fazer. Uma vez feliz com o port, a única coisa que resta é colocá-lo na árvore principal do FreeBSD e deixar todo mundo feliz também. Nós não precisamos do diretório work ou do pacote pkgname.tgz, então exclua-os agora. Em seguida, crie um patch1 ou um arquivo shar1. Assumindo que o port é chamado oneko e está na categoria games. Criando um <filename>.diff</filename> para um Novo Port. Adicione todos os arquivos com svn add. Utilize o cd e vá para a base da árvore de ports, para que os caminhos completos dos arquivos alterados sejam incluídos no diff, então gere o diff com svn diff. Por exemplo: % svn add . % cd ../.. % svn diff games/oneko > oneko.diff Para ser mais fácil para os committers aplicarem o patch em sua cópia de trabalho da árvore de ports, por favor, gere o .diff da base da sua árvore de ports. Criando um <filename>.shar</filename> para um Novo Port. Utilize o cd e vá para o diretório acima de onde o diretório do port está localizado e use shar para criar o arquivo: % cd .. % shar `find oneko` > oneko.shar Envie um dos oneko.shar ou oneko.diff com o formulário de submissão de bugs. Use product Ports & Packages, component Individual Port(s) e siga as diretrizes mostradas lá. Adicione uma breve descrição do programa ao campo Description do PR (talvez uma versão curta do COMMENT), e lembre-se de adicionar o oneko.shar ou oneko.diff como um anexo. Dar uma boa descrição no resumo do relatório de problema facilita muito o trabalho dos commiters de ports. Preferimos algo como New port: category/portname breve descrição do port para novos ports. Usar este esquema torna mais fácil e rápido começar o trabalho para fazer o commit de um novo port. Depois de enviar o port, por favor, seja paciente. O tempo necessário para incluir um novo port no FreeBSD pode variar de alguns dias até alguns meses. Um formulário simples de pesquisa no banco de dados do Relatório de Problemas está disponível em Para obter uma listagem dos PRs abertos para os ports, selecione Open e Ports & Packages no formulário de pesquisa, clique em [ Search ]. Depois de analisar o novo port, nós responderemos se necessário, e iremos adicioná-lo a árvore. O nome do remetente também será adicionado à lista de Contribuidores Adicionais do FreeBSD e outros arquivos. Port Lento Certo, então não foi tão simples e o port precisou de algumas modificações para poder funcionar. Nesta seção, vamos explicar passo a passo como modificá-lo para que funcione com o paradigma do ports. Como as Coisas Funcionam Primeiro, esta é a sequência de eventos que ocorre quando o usuário executa make no diretório do port. Ter o bsd.port.mk aberto em outra janela enquanto lê esta seção realmente irá ajudar a entender melhor. Mas não se preocupe, não são muitas as pessoas que entendem exatamente como o bsd.port.mk funciona...:-) O target fetch é executado. O target fetch é responsável por garantir que o tarball exista localmente em DISTDIR. Se o fetch não puder encontrar os arquivos necessários no DISTDIR ele procurará a URL na variável MASTER_SITES, definida no Makefile, assim como nos nossos mirrors FTP nos quais colocamos os distfiles como backup. Em seguida, ele tentará buscar o arquivo de distribuição nomeado com FETCH, assumindo que o site solicitante tem acesso direto à Internet. Se isso for bem sucedido, ele salvará o arquivo em DISTDIR para uso futuro e continuará. O target extract é executado. Ele procura pelo arquivo de distribuição do port (normalmente um tarball compactado) em DISTDIR e irá descompactá-lo em um subdiretório temporário especificado por WRKDIR (padrão é work) O target patch é executado. Primeiro, quaisquer patches definidos em PATCHFILES são aplicados. Segundo, se arquivos de patch nomeados patch-* forem encontrados em PATCHDIR (padrão para o subdiretório files), eles serão aplicados neste momento em ordem alfabética. O target configure é executado. Ele pode fazer qualquer uma de muitas coisas diferentes. Se existir, scripts/configure é executado. E se HAS_CONFIGURE ou GNU_CONFIGURE está definido, WRKSRC/configure é executado. O target build é executado. Ele é responsável por mudar para o diretório de trabalho privado do port (WRKSRC) e compila-lo. O target stage é executado. Este coloca o conjunto final de arquivos construídos em um diretório temporário (STAGEDIR, Veja ). A hierarquia deste diretório espelha a do sistema no qual o pacote será instalado. O target package é executado. Ele cria um pacote usando os arquivos do diretório temporário criado durante o target stage e o pkg-plist do port. O target install é executado. Este instala o pacote criado durante o target package no host. As ações acima são padrão. Além disso, defina os targets pre-something ou post-something, ou insira scripts com esses nomes no subdiretório scripts, e eles serão executados antes ou depois das ações padrão serem executadas. Por exemplo, se houver um target post-extract definido no Makefile e um arquivo pre-build no subdiretório scripts, o target post-extract será chamado após as ações de extração regulares e pre-build será executado antes que as regras de compilação padrão sejam feitas. Recomenda-se usar targets no Makefile se as ações forem simples, porque será mais fácil para alguém descobrir que tipo de ação não padrão o port necessita. As ações padrão são feitas pelos targets do-something do bsd.port.mk. Por exemplo, os comandos para extrair um port estão no target do-extract. Se o target padrão não fizer o trabalho direito, redefina o target do-something no Makefile. O target principal (por exemplo, extract, configure, etc.) fazem nada mais do que certificar-se de que todos os estágios até aquele estão concluídos e chamar os targets ou scripts reais, e eles não pretendem ser alterados. Para consertar a extração, corrija do-extract, mas nunca mude a forma como extract opera! Além disso, o target post-deinstall é inválido e não é executado pela infraestrutura de ports. Agora que o que acontece quando o usuário digita make install é melhor entendido, vamos seguir as etapas recomendadas para criar o port perfeito. Obtendo os Fontes Originais Obtenha os fontes originais (normalmente) como um tarball compactado (foo.tar.gz ou foo.tar.bz2) e copie-o para DISTDIR. Use fontes do mainstream sempre que possível. Definir a variável MASTER_SITES para refletir onde o tarball original reside. Existem definições abreviadas para a maioria dos sites mainstream em bsd.sites.mk. Por favor, use esses sites - e as definições associadas—se for possível, para ajudar a evitar o problema de ter as mesmas informações repetidas várias vezes na base de origem. Como esses sites tendem a mudar com o tempo, isso se torna um pesadelo de manutenção para todos os envolvidos. Veja para detalhes. Se não houver nenhum site FTP/HTTP bem conectado à rede ou se puder encontrar apenas sites com formatos irritantemente não-padrão, coloque uma cópia em um servidor FTP ou HTTP confiável (por exemplo, uma home page). Se um lugar conveniente e confiável para colocar o distfile não puder ser encontrado, nós podemos hospedar em ftp.FreeBSD.org; no entanto, esta é a solução menos preferida. O distfile deve ser colocado em ~/public_distfiles/ da conta freefall de alguém. Peça para a pessoa que for fazer o commit do port para realizer isso. Essa pessoa também irá definir MASTER_SITES para LOCAL/username onde username é o seu login do cluster do FreeBSD. Se o distfile do port mudar o tempo todo sem nenhum tipo de atualização de versão pelo autor, considere colocar o distfile em uma página pessoal e liste-a como o MASTER_SITES primário. Tente falar com o autor do port para parar de fazer isso; Isso realmente ajuda a estabelecer algum tipo de controle de código-fonte. Hospedar uma versão específica impedirá que os usuários obtenham erros de checksum mismatch, e também irá reduzir a carga de trabalho dos mantenedores do nosso site FTP. Além disso, se houver apenas um site master para o port, recomenda-se armazenar um backup em uma home page e listá-lo como o MASTER_SITES secundário. Se o port exigir patches adicionais disponíveis na Internet, baixe-os também e coloque-os em DISTDIR. Não se preocupe se eles vierem de um site diferente de onde vem o tarball do código fonte principal, temos uma maneira de lidar com essas situações (veja a descrição PATCHFILES abaixo). Modificando o Port Desempacote uma cópia do tarball em um diretório privado e faça as alterações necessárias para que o port compile corretamente sob a versão atual do FreeBSD. Atenção dobrada nessas etapas, pois elas serão necessárias para automatizar o processo em breve. Tudo, incluindo a exclusão, adição ou modificação de arquivos, devem ser realizados usando um script automatizado ou um arquivo patch quando o port estiver finalizado. Se o port exigir interação/customização significativa do usuário para compilar ou instalar, dê uma olhada em um dos scripts Configure clássicos de Larry Wall e talvez faça algo semelhante. O objetivo da nova coleção de ports é fazer com que cada port seja plug-and-play o quanto possível para o usuário final, usando um mínimo de espaço em disco. A menos que explicitamente declarado, os arquivos de patch, scripts e outros arquivos criados e contribuídos para a coleção de ports do FreeBSD são assumidos como cobertos pelas condições de copyright padrão do BSD. Patching Na preparação do port, arquivos que forem adicionados ou alterados podem ser gravados com diff1 para posterior inclusão em um patch1. Fazer isso com um arquivo típico envolve salvar uma cópia do arquivo original antes de fazer qualquer alteração usando um sufixo .orig. % cp file file.orig Depois que todas as alterações forem realizadas, cd de volta ao diretório do port. Execute make makepatch para gerar arquivos de patch atualizados no diretório files. Usar BINARY_ALIAS para substituir comandos codificados durante a compilação e para evitar patching de arquivos de compilação. Veja para maiores informações. Regras Gerais para Patching Arquivos patch são armazenados em PATCHDIR, geralmente files/, de onde serão aplicados automaticamente. Todas os patches devem ser relativos ao WRKSRC. Tipicamente WRKSRC é um subdiretório de WRKDIR, o diretório onde o distfile é extraído. Execute make -V WRKSRC para ver o caminho real. Os nomes dos patches devem seguir estas regras: Evite ter mais de um patch modificando o mesmo arquivo. Por exemplo, ter os dois patch-foobar.c e patch-foobar.c2 fazendo alterações em ${WRKSRC}/foobar.c torna-os frágeis e difíceis de serem depurados. Ao criar nomes para arquivos de patch, substitua cada underline (_) com dois underlines (__) e cada barra (/) com um underline (_). Por exemplo, para corrigir um arquivo chamado src/freeglut_joystick.c nomeie o patch correspondente patch-src_freeglut__joystick.c. Não nomeie patches como patch-aa ou patch-ab. Sempre use o caminho e o nome do arquivo nos nomes dos patches. O make makepatch gera automaticamente os nomes corretos. Um patch pode modificar vários arquivos se as alterações estiverem relacionadas e o patch tiver o nome apropriado. Por exemplo, patch-add-missing-stdlib.h. Use apenas caracteres [-+._ a-zA-Z0-9] para nomear patches. Em particular, não use :: como um separador de path, use _ no lugar. Minimize a quantidade de mudanças de espaço em branco não funcionais em patches. É comum no mundo Open Source para projetos compartilhar grandes quantidades de uma base de código, mas obedecer a regras de recuo e estilo diferentes. Ao usar uma funcionalidade funcional de um projeto para consertar áreas similares em outra, por favor, tenha cuidado: o patch resultante pode estar cheio de mudanças não-funcionais. Ele não só aumenta o tamanho do repositório do ports, mas torna difícil descobrir o que exatamente causou o problema e o que foi alterado em todos. Se um arquivo precisar ser excluído, faça-o no target post-extract em vez de como parte do patch. Geração Manual de Patches A criação manual de patches geralmente não é necessária. A geração automática de patches, conforme descrito anteriormente nesta seção, é o método preferido. No entanto, patches manuais podem ser necessários ocasionalmente. Patches são salvos em arquivos nomeados como patch-* onde * indica o nome do caminho do arquivo que está sendo feito o patch, como patch-imakefile ou patch-src-config.h. Depois que o arquivo foi modificado, diff1 é usado para registrar as diferenças entre a versão original e a modificada. faz com que o diff1 produza diffs unificados, a forma preferida. % diff -u file.orig file > patch-pathname-file Ao gerar patches para novos arquivos adicionados, é usado para dizer ao diff1 para tratar o arquivo original inexistente como se existisse, mas estava vazio: % diff -u -N newfile.orig newfile > patch-pathname-newfile Não adicione Strings RCS $FreeBSD$ em patches. Quando os patches são adicionados ao repositório Subversion com svn add, a propriedade fbsd:nokeywords é definida para yes automaticamente para que as keywords no patch não sejam modificadas no commit. A propriedade pode ser adicionada manualmente svn propset fbsd:nokeywords yes files.... Usar a opção () do diff1 para gerar patches é razoável, mas por favor, analise os patches resultantes para se certificar de que não há nenhum lixo desnecessário neles. Em particular, diffs entre dois arquivos de backup, quando o port usa Imake ou GNU configure, etc., diffs de Makefiles são desnecessários e devem ser eliminados. Se for necessário editar o configure.in e executar o autoconf para regerar o configure, não gere diffs do configure (ele geralmente cresce para algumas milhares de linhas!). Em vez disso, defina USES=autoreconf e gere os diffs no configure.in. Substituições Automáticas Simples Substituições simples podem ser realizadas diretamente do Makefile do port usando o modo in-loco do sed1. Isso é útil quando as alterações usam o valor de uma variável: post-patch: @${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README Muitas vezes, o software sendo portado usa a convenção CR/LF nos arquivos fonte. Isso pode causar problemas com correções adicionais, avisos do compilador ou execução de scripts (como /bin/sh^M não encontrado.) Para converter rapidamente todos os arquivos de CR/LF para apenas LF, adicione essa entrada ao Makefile do port: USES= dos2unix Uma lista de arquivos específicos para conversão pode ser informada: USES= dos2unix DOS2UNIX_FILES= util.c util.h Use DOS2UNIX_REGEX para converter um grupo de arquivos em subdiretórios. Seu argumento é um find1 compatível com expressão regular. Mais sobre o formato está em re_format7. Esta opção é útil para converter todos os arquivos de uma determinada extensão. Por exemplo, converta todos os arquivos de código-fonte, deixando os arquivos binários intactos: USES= dos2unix DOS2UNIX_REGEX= .*\.([ch]|cpp) Uma opção similar é DOS2UNIX_GLOB, que executa o find para cada elemento listado nele. USES= dos2unix DOS2UNIX_GLOB= *.c *.cpp *.h O diretório base para a conversão pode ser definido. Isso é útil quando há vários distfiles e vários arquivos contidos que requerem conversão de fim de linha. USES= dos2unix DOS2UNIX_WRKSRC= ${WRKDIR} Corrigindo Condicionalmente Alguns ports precisam de patches que são aplicados apenas para versões específicas do FreeBSD ou quando uma determinada opção é ativada ou desativada. Os patches condicionais são especificados colocando-se os caminhos completos para os arquivos de patch emEXTRA_PATCHES. Aplicando um Patch para uma Versão Específica do FreeBSD .include <bsd.port.options.mk> # Patch in the iconv const qualifier before this .if ${OPSYS} == FreeBSD && ${OSVERSION} < 1100069 EXTRA_PATCHES= ${PATCHDIR}/extra-patch-fbsd10 .endif .include <bsd.port.mk> Aplicando Opcionalmente um Patch Quando um option requer um patch, useopt_EXTRA_PATCHES e opt_EXTRA_PATCHES_OFF para fazer o patch condicional na opção opt. Veja Para maiores informações. OPTIONS_DEFINE= FOO BAR FOO_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-foo BAR_EXTRA_PATCHES_OFF= ${PATCHDIR}/extra-patch-bar.c \ ${PATCHDIR}/extra-patch-bar.h Usando <varname>EXTRA_PATCHES</varname> Com um Diretório As vezes, existem muitos patches que são necessários para um recurso, neste caso, é possível apontar EXTRA_PATCHES para um diretório, e ele aplicará automaticamente todos os arquivos nomeados como patch* nele. Crie um subdiretório em ${PATCHDIR}, e mova os patches para ele. Por exemplo: % ls -l files/foo-patches -rw-r--r-- 1 root wheel 350 Jan 16 01:27 patch-Makefile.in -rw-r--r-- 1 root wheel 3084 Jan 18 15:37 patch-configure Então adicione isso ao Makefile: OPTIONS_DEFINE= FOO FOO_EXTRA_PATCHES= ${PATCHDIR}/foo-patches O framework irá então usar todos os arquivos nomeados patch* nesse diretório. Configurando Inclua quaisquer comandos de personalização adicionais no script configure e salve-o no subdiretório scripts. Como mencionado acima, também é possível fazer isso com targets no Makefile e/ou scripts com o nome pre-configure ou post-configure. Manipulando a Entrada do Usuário Se o port requer intervenção do usuário para build, configure ou install, defina IS_INTERACTIVE no Makefile. Isso fará com que os overnight builds pulem ele. Se o usuário definir a variável BATCH em seu ambiente (e se o usuário definir a variável INTERATIVE, então apenas aqueles ports que requerem interação serão compilados). Isso economizará muito tempo perdido no conjunto de máquinas que continuamente compilam ports (veja abaixo). Também é recomendado que, se houver respostas padrão razoáveis ​​para as perguntas, PACKAGE_BUILDING pode usado para desativar a intervenção do usuário quando o mesmo estiver definido. Isso nos permitirá compilar os pacotes para CDROMs e FTP. Configurando o Makefile Configurar o Makefile é bastante simples e, novamente, sugerimos examinar os exemplos existentes antes de começar. Além disso, há um Makefile de exemplo neste manual, então dê uma olhada e por favor siga a ordem das variáveis ​​e seções naquele modelo para tornar o port mais fácil para os outros lerem. Considere estes problemas em sequência durante o projeto do novo Makefile: O Código Fonte Original Ele está em DISTDIR como um tarball gzip e é chamado de algo como foozolix-1.2.tar.gz? Se assim for, vá para o próximo passo. Caso contrário, o formato do arquivo de distribuição pode necessitar da substituição de uma ou mais das variáveis DISTVERSION, DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX ou DISTFILES. Na pior das hipóteses, crie um target personalizado do-extract para substituir o padrão. Isso raramente é necessário. Nomeando A primeira parte do Makefile do port o nomeia, descreve seu número de versão e o lista na categoria correta. <varname>PORTNAME</varname> Setar PORTNAME ao nome base do software. Isso é usado como base para o pacote do FreeBSD, e para o DISTNAME. O nome do pacote deve ser único em toda a árvore de ports. Certifique-se de que o PORTNAME já não está em uso por um port existente, e que nenhum outro port já tem o mesmo PKGBASE. Se o nome já tiver sido usado, adicione PKGNAMEPREFIX ou PKGNAMESUFFIX. Versões, <varname>DISTVERSION</varname><emphasis> ou </emphasis><varname>PORTVERSION</varname> Setar DISTVERSION para o número da versão do software. PORTVERSION é a versão usada para o pacote do FreeBSD. Será automaticamente derivado de DISTVERSION para ser compatível com o esquema de versionamento de pacotes do FreeBSD. Se a versão contiver letras, pode ser necessário definir PORTVERSIONe não DISTVERSION. Não é possível utilizar PORTVERSION e DISTVERSION juntos, deve ser ser definido um de cada vez. De tempos em tempos, alguns softwares usam um esquema de versão que não é compatível em como o DISTVERSION traduz a versão no PORTVERSION. Ao atualizar um port, é possível usar o pkg-version8 para verificar se a nova versão é maior ou menor do que antes. Veja . Usando <citerefentry><refentrytitle>pkg-version</refentrytitle><manvolnum>8</manvolnum></citerefentry> para comparar versões. pkg version -t recebe duas versões como argumentos, responderá com <, = ou > se a primeira versão for menor, igual ou maior que a segunda versão, respectivamente. % pkg version -t 1.2 1.3 < % pkg version -t 1.2 1.2 = % pkg version -t 1.2 1.2.0 = % pkg version -t 1.2 1.2.p1 > % pkg version -t 1.2.a1 1.2.b1 < % pkg version -t 1.2 1.2p1 < 1.2 é menor que 1.3. 1.2 e 1.2 são iguais, pois têm a mesma versão. 1.2 e 1.2.0 são iguais, pois valor vazio é igual a zero. 1.2 é maior que 1.2.p1 por causa do .p1, pense em pre-release 1. 1.2.a1 é menor que 1.2.b1, pense em alfa e beta e a é menor que b. 1.2 é menor que 1.2p1 por causa do 2p1, pense em 2, nível de patch 1 que é uma versão depois de qualquer 2.X mas antes de 3. Aqui, a, b e p são usados ​​como se significassem alfa, beta ou pre-release e nível de patch, mas elas são apenas letras e são classificados por ordem alfabética, portanto, qualquer letra pode ser utilizada, e elas serão ordenadas de forma adequada. Exemplos de <varname>DISTVERSION</varname> e de Derivações <varname>PORTVERSION</varname>. DISTVERSION PORTVERSION 0.7.1d 0.7.1.d 10Alpha3 10.a3 3Beta7-pre2 3.b7.p2 8:f_17 8f.17
Usando <varname>DISTVERSION</varname> Quando a versão contém apenas números separados por pontos, traços ou sublinhados, use DISTVERSION. PORTNAME= nekoto DISTVERSION= 1.2-4 Isso irá gerar um PORTVERSION 1.2.4. Usando <varname>DISTVERSION</varname> Quando a Versão Começa com uma Letra ou um Prefixo Quando a versão começa ou termina com uma letra, um prefixo ou um sufixo que não faz parte da versão, use DISTVERSIONPREFIX, DISTVERSION e DISTVERSIONSUFFIX. Se a versão for v1.2-4: PORTNAME= nekoto DISTVERSIONPREFIX= v DISTVERSION= 1_2_4 Algumas vezes, projetos usando GitHub usará seu nome em suas versões. Por exemplo, a versão pode ser nekoto-1.2-4: PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2_4 Esses projetos também usam algumas strings no final da versão, por exemplo,1.2-4_RELEASE: PORTNAME= nekoto DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE Ou eles fazem ambos, por exemplo,nekoto-1.2-4_RELEASE: PORTNAME= nekoto DISTVERSIONPREFIX= nekoto- DISTVERSION= 1.2-4 DISTVERSIONSUFFIX= _RELEASE DISTVERSIONPREFIX e DISTVERSIONSUFFIX não serão usados durante a construção do PORTVERSION, mas usado apenas em DISTNAME. Todos exemplos irão gerar um PORTVERSION com valor 1.2.4. Usando <varname>DISTVERSION</varname> Quando a Versão Contém Letras Significando <quote>alpha</quote>, <quote>beta</quote> ou <quote>pre-release</quote> Quando a versão contém números separados por pontos, traços ou underlines, e letras são usadas para significar alpha, beta ou pre-release, no sentido de que vem antes das versões sem letras, use DISTVERSION. PORTNAME= nekoto DISTVERSION= 1.2-pre4 PORTNAME= nekoto DISTVERSION= 1.2p4 Ambos irão gerar um PORTVERSION com valor 1.2.p4 que é menor do que 1.2. pkg-version8 pode ser usado para verificar esse fato: % pkg version -t 1.2.p4 1.2 < Não use <varname>DISTVERSION</varname> Quando a Versão Contém Letras que Significam "Nível de Patch" Quando a versão contém letras que não significam alpha, beta ou pre, e estão mais para um nível de patch, no sentido de que vem depois da versão sem as letras, use PORTVERSION. PORTNAME= nekoto PORTVERSION= 1.2p4 Neste caso, usar DISTVERSION não é possível porque geraria uma versão 1.2.p4 o que seria menor que 1.2 e não maior.pkg-version8 irá constatar isso: % pkg version -t 1.2 1.2.p4 > % pkg version -t 1.2 1.2p4 < 1.2 é maior que 1.2.p4, o que é errado nesse caso. 1.2 é menor que 1.2p4, que é o que era necessário. Para alguns exemplos mais avançados de configuração do PORTVERSION, quando a versão do software não é realmente compatível com o FreeBSD, ou DISTNAME quando o arquivo de distribuição não contém a versão em si, consulte . <varname>PORTREVISION</varname> e <varname>PORTEPOCH</varname> <varname>PORTREVISION</varname> PORTREVISION é um valor monotonicamente crescente que é redefinido para 0 com cada incremento de DISTVERSION, normalmente toda vez que houver uma nova versão oficial do fornecedor. E se PORTREVISION é diferente de zero, o valor é anexado ao nome do pacote. Mudanças em PORTREVISION são usadas ​​por ferramentas automatizadas como pkg-version8 para determinar se um novo pacote está disponível. PORTREVISION deve ser incrementado toda vez que uma alteração for feita no port onde se altera o pacote gerado de alguma forma. Isso inclui alterações que afetam apenas um pacote compilado com options não padrão. Exemplos de quando PORTREVISION deve ser alterado: Adição de correções para corrigir vulnerabilidades de segurança, bugs ou para adicionar novas funcionalidades ao port. Alterações no Makefile do port para ativar ou desativar as opções de tempo de compilação no pacote. Alterações na lista de empacotamento ou no comportamento de tempo de instalação do pacote. Por exemplo, uma alteração em um script que gera dados iniciais para o pacote, como chaves de host ssh1. Bump de versão da dependência de biblioteca compartilhada de um port (nesse caso, alguém tentando instalar o pacote antigo depois de instalar uma versão mais nova da dependência falhará, pois procurará a libfoo.x antiga em vez da libfoo.(x+1)). Mudanças silenciosas no distfile do port que possuem diferenças funcionais significativas. Por exemplo, mudanças no distfile que requerem uma correção para distinfo sem alteração correspondente para DISTVERSION, onde umdiff -ru das versões antiga e nova mostra mudanças não triviais no código. Exemplos de alterações que não requerem uma alteração no PORTREVISION: Mudanças de estilo no esqueleto do port sem alteração funcional ao que aparece no pacote resultante. Mudanças para MASTER_SITES ou outras alterações funcionais no port que não afetem o pacote resultante. Patches triviais para o distfile, como correção de erros de digitação, que não são importantes o suficiente para que os usuários do pacote tenham que se dar ao trabalho de atualizar. Correções de compilação que fazem com que um pacote se torne compilável onde antes estava falhando. Desde que as alterações não introduzam nenhuma mudança funcional em nenhuma outra plataforma na qual o port tenha sido compilado anteriormente. PORTREVISION reflete o conteúdo do pacote, se o pacote não foi compilado anteriormente, então não há necessidade de incrementar o PORTREVISION para registrar uma mudança. Uma regra geral é decidir se a mudança em um port é algo que algumas pessoas se beneficiariam em ter. Por causa de um aprimoramento, conserto ou em virtude de que o novo pacote funcione de fato. Em seguida, pondere que, de fato, isso fará com que todos que regularmente atualizam sua árvore de ports sejam obrigados a atualiza-lo. Se sim, PORTREVISION deve ser incrementado. Pessoas usando pacotes binários nunca verão a atualização se PORTREVISION não for incrementado. Sem incrementar PORTREVISION, os package builders não têm como detectar a alteração e, portanto, não irão recompilar o pacote. <varname>PORTEPOCH</varname> De tempos em tempos, um fornecedor de software ou um mantenedor de port do FreeBSD fazem algo tolo e lançam uma versão de seu software que é numericamente menor que a versão anterior. Um exemplo disso é um port que vai de foo-20000801 para foo-1.0 ( o primeiro será incorretamente tratado como uma versão mais nova, já que 20000801 é um valor numericamente maior que 1). Os resultados das comparações de números de versão nem sempre são óbvios. pkg version (veja pkg-version8) pode ser usado para testar a comparação de duas sequências de números de versão. Por exemplo: % pkg version -t 0.031 0.29 > A saida > indica que a versão 0.031 é considerada maior que a versão 0.29, o que pode não ter sido óbvio para o mantenedor do port. Em situações como essa, PORTEPOCH deve ser incrementado. E se PORTEPOCH é diferente de zero, ele é anexado ao nome do pacote conforme descrito na seção 0 acima. PORTEPOCH nunca deve ser diminuído ou redefinido para zero, porque isso faria com que a comparação com um pacote de uma época anterior falhasse. Por exemplo, o pacote não seria detectado como desatualizado. O novo número da versão, 1.0.1 no exemplo acima, ainda é numericamente menor que a versão anterior, 20000801, mas o sufixo 1 é tratado especialmente por ferramentas automatizadas e considerado maior que o sufixo 0 implícito no pacote anterior. Remover ou resetar o PORTEPOCH incorretamente conduz ao luto eterno. Se a discussão acima não foi clara o suficiente, por favor consulte a Lista de discussão de ports do FreeBSD É esperado que PORTEPOCH não seja utilizado na maioria dos ports, e que seja feito o uso sensato do DISTVERSION, ou que o PORTVERSION seja usado com cuidado também, isso muitas vezes pode evitar que uma versão futura do software altere a estrutura da versão. No entanto, é necessário que os porters do FreeBSD tenham cuidado quando uma versão do fornecedor é feita sem um número de versão oficial - como um código de release snapshot. A tentação é rotular a release com a data de lançamento, o que causará problemas como no exemplo acima, quando um novo release oficial é feito. Por exemplo, se um snapshot de release é feito na data 20000917 e a versão anterior do software era a versão 1.2, não use 20000917 no DISTVERSION. A maneira correta é um DISTVERSION com valor 1.2.20000917, ou similar, para que a próxima versão, digamos 1.3, ainda seja um valor numericamente maior. Exemplo de Uso <varname>PORTREVISION</varname> e <varname>PORTEPOCH</varname> O port gtkmumble, versão0.10 está comitado na coleção de ports: PORTNAME= gtkmumble DISTVERSION= 0.10 PKGNAME torna-se gtkmumble-0.10. Uma falha de segurança é descoberta, o que requer um patch local do FreeBSD. PORTREVISION é alterado de acordo. PORTNAME= gtkmumble DISTVERSION= 0.10 PORTREVISION= 1 PKGNAME torna-se gtkmumble-0.10_1 Uma nova versão é lançada pelo fornecedor, numerada como 0.2 (acontece que o autor realmente pretendia que 0.10 significa-se realmente 0.1.0, não o que vem depois de 0.9 - oops, tarde demais agora). Como a nova versão secundária 2 é numericamente menor que a versão anterior 10, PORTEPOCH deve ser incrementado para forçar manualmente que o novo pacote seja detectado como mais recente. Como é uma nova versão do fornecedor, PORTREVISION é redefinido para 0 (ou removido doMakefile). PORTNAME= gtkmumble DISTVERSION= 0.2 PORTEPOCH= 1 PKGNAME torna-se gtkmumble-0.2,1 O próximo lançamento é 0.3. Desde que PORTEPOCH nunca diminua, as variáveis ​​de versão são agora: PORTNAME= gtkmumble DISTVERSION= 0.3 PORTEPOCH= 1 PKGNAME torna-se gtkmumble-0.3,1 E se PORTEPOCH for redefinido para 0 com esta atualização, alguém que instalou o gtkmumble-0.10_1 não detectaria o gtkmumble-0.3 como pacote mais novo, desde que 3 ainda é numericamente menor que 10. Lembre-se, este é o ponto principal de PORTEPOCH em primeiro lugar. <varname>PKGNAMEPREFIX</varname> e <varname>PKGNAMESUFFIX</varname> Duas variáveis ​​opcionais, PKGNAMEPREFIX e PKGNAMESUFFIX, são combinadas com PORTNAME e PORTVERSION para formar PKGNAME como ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Certifique-se de que isto está de acordo com as nossas diretrizes para um bom nome de pacote. Em particular, o uso de um hífen (-) dentro de PORTVERSION não é permitido. Além disso, se o nome do pacote tiver o language- ou a parte -compiled.specifics (veja abaixo), use PKGNAMEPREFIX e PKGNAMESUFFIX, respectivamente. Não os faça parte de PORTNAME. Convenções de Nomenclatura de Pacotes Estas são as convenções a serem seguidas ao nomear pacotes. Isso é para facilitar a varredura do diretório de pacotes, já que existem milhares de pacotes e os usuários irão pegar ranço se eles machucarem seus olhos! Nomes de pacotes tomam a forma de language_region-name-compiled.specifics-version.numbers. O nome do pacote é definido como ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Certifique-se de definir as variáveis ​​para estar em conformidade com esse formato. language_region- O FreeBSD se esforça para suportar a linguagem nativa de seus usuários. A parte language- é uma abreviação de duas letras da linguagem natural definida pela ISO-639 quando o port é específico para um determinado idioma. Exemplos são ja para japonês, ru para russo,vi para vietnamita, zh para o chinês, ko para coreano e de para alemão. Se o port for específico de uma determinada região dentro da área de idioma, adicione também o código do país de duas letras. Exemplos são en_US para Inglês dos EUA e fr_CH para o Francês Suíço. A parte language- é definida em PKGNAMEPREFIX. name Certifique-se de que o nome e a versão do port estejam claramente separados e colocados em PORTNAME e DISTVERSION. A única razão para PORTNAME conter uma parte da versão é se a distribuição upstream é realmente chamada dessa forma, como no textproc/libxml2 ou japanese/kinput2-freewnn. De outra forma, PORTNAME não pode conter informações específicas da versão. É normal que vários ports tenham o mesmo PORTNAME, como os ports www/apache * fazem; Nesse caso, versões diferentes (e entradas de índice diferentes) são distinguidas por valores PKGNAMEPREFIX e PKGNAMESUFFIX. Há uma tradição de nomear módulos Perl 5 com sufixo p5- e convertendo o separador de dois pontos para um hífen. Por exemplo, o modulo Data::Dumper torna-se p5-Data-Dumper. -compiled.specifics Se o port pode ser construído com diferentes padrões codificados (geralmente parte do nome do diretório em uma família de ports), a parte -compiled.specifics indica os padrões compilados. O hífen é opcional. Exemplos são tamanho de papel e unidades de fonte. A parte -compiled.specifics é definida em PKGNAMESUFFIX. -version.numbers A string da versão segue um hífen (-) e é uma lista separada por pontos de números inteiros e letras minúsculas. Em particular, não é permitido ter outro hífen dentro da string de versão. A única exceção é a string pl (significando patchlevel), que pode ser usado apenas quando não há números de versão maiores e menores no software. Se a versão do software tiver sequências como alpha, beta, rc ou pre, use a primeira letra e coloque imediatamente após um ponto. Se a sequência da versão continuar após esses nomes, os números seguirão o alfabeto simples sem um ponto extra entre eles (por exemplo,1.0b2). A ideia é facilitar a classificação dos ports observando a string de versão. Em particular, certifique-se de que os componentes do número da versão estejam sempre delimitados por um ponto e, se a data fizer parte da string, use o formato dyyyy.mm.dd, não dd.mm.yyyy ou o não compatível com o formato Y2K yy.mm.dd. É importante prefixar a versão com uma letra, aquid (para data), no caso de uma versão com um número de versão real, que seria numericamente inferior a yyyy. O nome do pacote deve ser único entre todos os ports, verifique se ainda não existe um port com o mesmo PORTNAME e se houver, adicione um dos PKGNAMEPREFIX ou PKGNAMESUFFIX. Aqui estão alguns exemplos (reais) de como converter o nome como chamado pelos autores do software para um nome de pacote adequado, para cada linha, apenas um dos DISTVERSION ou PORTVERSION está definido, dependendo de qual seria usado no Makefile: Exemplos de Nomes de Pacotes Nome da Distribuição PKGNAMEPREFIX PORTNAME PKGNAMESUFFIX DISTVERSION PORTVERSION Razão ou comentário mule-2.2.2 (vazio) mule (vazio) 2.2.2 Nenhuma alteração é necessária mule-1.0.1 (vazio) mule 1 1.0.1 Esta é a versão 1 do mule e a versão 2 já existe. EmiClock-1.0.2 (vazio) emiclock (vazio) 1.0.2 Sem nomes em maiúsculas para programas individuais rdist-1.3alpha (vazio) rdist (vazio) 1.3alfa Versão será 1.3.a es-0.9-beta1 (vazio) es (vazio) 0.9-beta1 Versão será 0.9.b1 mailman-2.0rc3 (vazio) mailman (vazio) 2.0rc3 Versão será2.0.r3 v3.3beta021.src (vazio) tiff (vazio) 3.3 O que diabos foi isso afinal? tvtwm (vazio) tvtwm (vazio) p11 Nenhuma versão no nome do arquivo, use o que o upstream diz que é piewm (vazio) piewm (vazio) 1.0 Nenhuma versão no nome do arquivo, use o que o upstream diz que é xvgr-2.10pl1 (vazio) xvgr (vazio) 2.10.pl1 Nesse caso,pl1 significa nível de patch, então usar DISTVERSION não é possível. gawk-2.15.6 ja- gawk (vazio) 2.15.6 Versão em japonês psutils-1.13 (vazio) psutils -letter 1.13 Tamanho do papel codificado no tempo de compilação do pacote pkfonts (vazio) pkfonts 300 1.0 Pacote para fontes de 300dpi
Se não houver absolutamente nenhum rastro de informações de versão co código fonte original e é improvável que o autor original vá liberar outra versão, basta definir a string de versão para 1.0 (como o exemplo piewm acima). Caso contrário, pergunte ao autor original ou use a string de data com valor de quando a código fonte foi lançado como (dyyyy.mm.dd ou dyyyymmdd) como a versão. Use qualquer letra. Aqui,d significa data, se o código for um repositório do Git, g seguido pela data de commit é normalmente utilizado, s para snapshot também é comum. Categorização <varname>CATEGORIES</varname> Quando um pacote é criado, ele é colocado em /usr/ports/packages/All e links são feitos de um ou mais subdiretórios de /usr/ports/packages. Os nomes desses subdiretórios são especificados pela variável CATEGORIES. O objetivo é facilitar a vida do usuário quando ele estiver vasculhando a pilha de pacotes no site FTP ou no CD-ROM. Por favor, dê uma olhada na lista atual de categorias e escolha as que são adequadas para o port. Esta lista também determina de onde, na árvore de ports, o port será importado. Se houver mais de uma categoria aqui, os arquivos do port devem ser colocados no subdiretório com o nome da primeira categoria. Veja abaixo para mais informação sobre como escolher as categorias certas. Lista Atual de Categorias Aqui está a lista atual de categorias de ports. As marcadas com um asterisco (*) são categorias virtuais - aquelas que não possuem um subdiretório correspondente na árvore de ports. Elas são usadas ​​apenas como categorias secundárias e apenas para fins de pesquisa. Para categorias não virtuais, há uma descrição de uma linha em COMMENT no Makefile desse subdiretório. Categoria Descrição Notas accessibility Ports para ajudar usuários com deficiências. afterstep * Ports para apoiar o gerenciador de janelas AfterStep. arabic Suporte ao idioma árabe" archivers Ferramentas de arquivamento. astro Ports astronômicos. audio Suporte de som. benchmarks Utilitários de benchmarking. biology Software relacionado à biologia. cad Ferramentas de desenho assistidas por computador. chinese Suporte ao idioma chinês. comms Software de comunicação. Principalmente software para falar com o port serial. converters Conversores de código de caracteres. databases Bancos de dados. deskutils Coisas que costumavam estar na área de trabalho antes dos computadores serem inventados. devel Utilitários de desenvolvimento. Não coloque bibliotecas aqui só porque são bibliotecas. Elas não deveriam estar nesta categoria, a menos que elas realmente não pertençam a nenhum outro lugar. dns Software relacionado ao DNS. docs * Meta-ports para documentação do FreeBSD. editors Editores gerais. Editores especializados entram na seção para essas ferramentas. Por exemplo, um editor de fórmula matemática math, e tem editores como uma segunda categoria. elisp * Emacs-lisp ports. emulators Emuladores para outros sistemas operacionais. Emuladores de terminal não estão aqui. Os baseados em X vão para o x11 e baseados em texto para qualquer comms ou misc, dependendo da funcionalidade exata. finance Aplicações monetárias, financeiras e relacionadas. french Suporte ao idioma francês. ftp Utilitários de cliente e servidor deFTP. Se o port fala com FTP e HTTP, coloque-o em ftp com uma categoria secundária de www. games Jogos. geography * Software relacionado à geografia. german Suporte ao idioma alemão. gnome * Ports do ProjetoGNOME. gnustep * Software relacionado ao ambiente de desktop GNUstep. graphics Utilitários gráficos. hamradio * Software para rádio amador. haskell * Software relacionado à linguagem Haskell. hebrew Suporte ao idioma hebraico. hungarian Suporte de idioma húngaro. ipv6 * Software relacionado ao IPv6 irc Utilitários do Internet Relay Chat. japanese Suporte ao idioma japonês. java Software relacionado à linguagem Java™. A categoria Java não deve ser única para um port. Salvo para ports diretamente relacionadas à linguagem Java, os mantenedores de ports também são encorajados a não usar Java como a principal categoria de um port. kde * Ports do ProjetoKDE. kld * Módulos carregáveis ​​do kernel. korean Suporte ao idioma coreano. lang Linguagens de programação. linux * Aplicações Linux e utilitários de suporte. lisp * Software relacionado à linguagem Lisp. mail Mail software. math Software de computação numérica e outras utilidades para matemática. mbone * Aplicações MBone. misc Utilitários diversos Coisas que não pertencem em nenhum outro lugar. Se possível, tente encontrar uma categoria melhor para o port do que misc, como os ports tendem a ser negligenciados aqui. multimedia Software multimídia. net Software de rede diversos. net-im Software de mensagens instantâneas. net-mgmt Software de gerenciamento de rede. net-p2p Aplicativos de rede peer to peer. news Software de notícias USENET. palm Suporte de software para a série Palm ™. parallel * Aplicativos que lidam com o paralelismo na computação. pear * Ports relacionados ao framework PHP Pear. perl5 * Ports que exigem Perl versão 5 para rodar. plan9 * Vários programas de Plan9. polish Suporte ao idioma polonês" ports-mgmt Ports para gerenciar, instalar e desenvolver ports e pacotes do FreeBSD. portuguese Suporte ao idioma Português. print Software de Impressão. As ferramentas de editoração eletrônica (pré-visualizadores etc.) também pertencem aqui. python * Software relacionado a linguagemPython. ruby * Software relacionado a linguagemRuby. rubygems * Ports de pacotes RubyGems. russian Suporte de idioma russo. scheme * Software relacionado à linguagem Scheme. science Ports científicos que não se encaixam em outras categorias, como astro, biologia e matemática security Utilitários de segurança. shells Linha de comando do shell. spanish * Suporte ao idioma espanhol. sysutils Utilidades do sistema. tcl * Ports que usam o Tcl para rodar. textproc Utilitários de processamento de texto. Não inclui ferramentas de editoração eletrônica, que vão para print tk * Ports que usam o Tk para rodar. ukrainian Suporte de idioma Ucraniano. vietnamese Suporte de idioma Vietnamita. windowmaker * Ports para suportar o gerenciador de janelas do WindowMaker. www Software relacionado à World Wide Web. O suporte ao idioma HTML também pertence aqui. x11 O X Window System e seus amigos. Esta categoria é apenas para software que suporta diretamente o sistema de janelas. Não coloque aplicativos regulares do X aqui. A maioria deles é usada em outras categorias x11- * (veja abaixo). x11-clocks X11 relógios. x11-drivers Drivers X11. x11-fm Gerentes de arquivos X11. x11-fonts Fontes X11 e utilitários de fonte. x11-servers Servidores X11. x11-themes X11 temas. x11-toolkits Kits de ferramentas X11. x11-wm Gerentes de janela do X11. xfce * Ports relacionados com o ambiente de trabalho Xfce. zope * Zope suporte. Escolhendo a Categoria Correta Como muitas das categorias se sobrepõem, escolher qual das categorias será a principal categoria do port pode ser entediante. Existem várias regras que governam essa questão. Aqui está a lista de prioridades, em ordem decrescente de precedência: A primeira categoria deve ser uma categoria física (veja acima). Isso é necessário para o empacotamento funcionar. Categorias virtuais e categorias físicas podem ser misturadas depois disso. As categorias específicas de idioma sempre vêm em primeiro lugar. Por exemplo, se o port instalar fontes X11 em japonês, a linha CATEGORIES deve ser japanese x11-fonts. Categorias específicas são listadas antes de outras menos específicas. Por exemplo, um editor de HTML é listado como www editors, e não ao contrário. Além disso, não insira net quando o port pertencer a qualquer uma das categorias irc, mail, news, security ou www, pois net está incluída implicitamente. x11 é usado como uma categoria secundária somente quando a categoria principal é uma linguagem natural. Em particular, não coloque x11 na linha de categoria em aplicações X. Os modes Emacs são colocados na mesma categoria de ports que a aplicação suportada pelo mode, e não em editors. Por exemplo, um mode Emacs para editar código fonte de alguma linguagem de programação entra em lang. Ports que instalam módulos do kernel carregáveis ​​também têm a categoria virtual kld na sua linha CATEGORIES. Esta é uma das coisas tratadas automaticamente adicionando USES=kmod. misc não aparece com nenhuma outra categoria não virtual. Se houver misc com outra categoria na linha CATEGORIES, isso significa que misc pode ser seguramente excluído e o port colocado apenas no outro subdiretório. Se o port realmente não pertencer em nenhum outro lugar, coloque-o em misc. Se a categoria não estiver claramente definida, por favor, insira um comentário sobre isso na submissão do port no banco de dados de bugs, para que possamos discuti-lo antes de importá-lo. Como committer, envie uma mensagem para a lista de discussão de ports do FreeBSD, para podermos discutir isso primeiro. Com muita frequência, novos ports são importados na categoria errada, e depois são movidos imediatamente para a categoria correta. Propondo uma Nova Categoria Como a Coleção de Ports vem crescendo com o tempo, várias novas categorias também são adicionadas. Novas categorias podem ser categorias virtuais- aquelas que não possuem um subdiretório correspondente na árvore de ports - ou físicas - aquelas que possuem. Esta seção discute os problemas envolvidos na criação de uma nova categoria física. Leia atentamente antes de propor uma nova. Nossa prática atual tem sido a de evitar a criação de uma nova categoria física, a menos que um grande número de ports logicamente pertençam a ela, ou os ports que pertenceriam a ela sejam um grupo logicamente distinto de interesse geral limitado (por exemplo, categorias relacionadas com as línguas humanas faladas), ou de preferência ambas. A razão para isto é que tal mudança cria uma quantidade grande de trabalho tanto para os committers quanto para todos os usuários que rastreiam alterações na coleção de ports. Além disso, propostas de alteração de categorias parecem naturalmente atrair controvérsias. (Talvez isso seja porque não há um consenso claro sobre quando uma categoria é grande o suficiente, nem quando as categorias devem ser apenas para propósitos de busca (e, portanto, qual número de categorias seria um número ideal), e assim por diante.). Aqui está o procedimento: Proponha a nova categoria na lista de discussão de ports do FreeBSD. Inclua uma justificativa detalhada para a nova categoria, incluindo por que as categorias existentes não são suficientes, e a lista de ports existentes propostos para a mudança. (Se houver novos ports pendentes no Bugzilla que caberia nessa categoria, liste-os também.) Se você for o mantenedor e/ou o apresentador, respectivamente, mencione isso, pois isso pode ajudar no caso. Participe da discussão. Se parecer que há apoio o suficiente para a ideia, registre um PR que inclua a lógica e a lista de ports existentes que precisam ser movidos. O ideal é que este PR também inclua essas alterações: Makefiles para os novos ports, uma vez que sejam recopiados Makefile para a nova categoria Makefile para as categorias dos ports antigos Makefiles para ports que dependem dos ports antigos (para crédito extra, inclua os outros arquivos que precisam ser alterados, conforme o procedimento no Guia do Committer.) Como isso afeta a infraestrutura do ports e envolve a movimentação e alteração de vários ports, pode ser necessário executar testes de regressão no cluster de build, e portanto, atribua o PR para a Equipe de Gerenciamento de Ports portmgr@FreeBSD.org. Se esse PR for aprovado, um committer precisará seguir o restante do procedimento que é descrito no Guia do Committer. A proposta de uma nova categoria virtual é semelhante à acima, mas muito menos trabalhoso, já que nenhum port terá que ser movido. Nesse caso, os únicos patches a serem incluídos no PR serão aqueles para adicionar a nova categoria na linha CATEGORIES dos ports afetados. Propondo Reorganizar Todas as Categorias Ocasionalmente alguém propõe reorganizar as categorias com uma estrutura de dois níveis, ou algum outro tipo de estrutura de palavras-chave. Até o momento, nada vem de nenhuma dessas propostas porque, embora sejam muito fáceis de fazer, o esforço envolvido com qualquer readequação de toda a coleção de ports existente é assustadora, para se dizer o mínimo. Por favor, leia o histórico dessas propostas nos arquivos da lista de discussão antes de postar essa idéia. Além disso, esteja preparado para ser desafiado a oferecer um protótipo funcional. Os Arquivos de Distribuição A segunda parte do Makefile descreve os arquivos que devem ser baixados para compilar o port e onde eles podem ser baixados. <varname>DISTNAME</varname> DISTNAME é o nome do port, conforme chamado pelos autores do software. DISTNAME é derivado de ${PORTNAME}-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX}, e se não estiver definido, DISTVERSION é derivado de ${PORTVERSION}, portanto altere DISTNAME somente se necessário. DISTNAME é usado apenas em dois lugares. Primeiro, na lista de arquivos de distribuição (DISTFILES) padrão para ${DISTNAME}${EXTRACT_SUFX}. Em segundo lugar, espera-se que o arquivo de distribuição seja extraído em um subdiretório denominado WRKSRC, cujo padrão é work/${DISTNAME}. Alguns nomes de distribuição de fornecedores que não se encaixam no ${PORTNAME}-${PORTVERSION}-scheme podem ser tratados automaticamente configurando DISTVERSIONPREFIX, DISTVERSION e DISTVERSIONSUFFIX. PORTVERSION será derivado de DISTVERSION automaticamente. Apenas um dos PORTVERSION e DISTVERSION pode ser definido de cada vez. E se DISTVERSION não derivar um PORTVERSION correto, não use DISTVERSION. Se o esquema de versão upstream puder ser derivado em um esquema de versão compatível com o ports, defina uma variável para a versão upstream, não use DISTVERSION como o nome da variável. Defina PORTVERSION para a versão computada com base na variável criada, e defina DISTNAME adequadamente. Se o esquema de versão upstream não puder ser facilmente configurado para um valor compatível com o ports, defina PORTVERSION para um valor sensato, e defina DISTNAME com PORTNAME com a versão literal do upstream. Derivando <varname>PORTVERSION</varname> Manualmente BIND9 usa um esquema de versão que não é compatível com as versões de ports (tem - em suas versões) e não pode ser derivado usando DISTVERSION porque após a versão 9.9.9, será lançado patchlevels na forma 9.9.9-P1. DISTVERSION iria traduzir isso para 9.9.9.p1, que no esquema de versionamento de ports significa 9.9.9 pré-release 1, que vem antes de 9.9.9 e não depois. Assim PORTVERSION é derivado manualmente de uma variável ISCVERSION para retornar 9.9.9p1. A ordem na qual o framework do ports e o pkg ordenará as versões, é verificada usando o argumento -t do pkg-version8: % pkg version -t 9.9.9 9.9.9.p1 > % pkg version -t 9.9.9 9.9.9p1 < O sinal > significa que o primeiro argumento passado em -t é maior que o segundo argumento. 9.9.9 é maior que 9.9.9.p1. O sinal < significa que o primeiro argumento passado em -t é menor que o segundo argumento. 9.9.9 é menor que 9.9.9p1. No Makefile do port, por exemplo dns/bind99, é alcançado por: PORTNAME= bind PORTVERSION= ${ISCVERSION:S/-P/P/:S/b/.b/:S/a/.a/:S/rc/.rc/} CATEGORIES= dns net ipv6 MASTER_SITES= ISC/bind9/${ISCVERSION} PKGNAMESUFFIX= 99 DISTNAME= ${PORTNAME}-${ISCVERSION} MAINTAINER= mat@FreeBSD.org COMMENT= BIND DNS suite with updated DNSSEC and DNS64 LICENSE= ISCL # ISC releases things like 9.8.0-P1 or 9.8.1rc1, which our versioning does not like ISCVERSION= 9.9.9-P6 Defina a versão upstream em ISCVERSION, com um comentário dizendo porque é necessário. Use ISCVERSION para obter um PORTVERSION compatível com o ports. Use ISCVERSION diretamente para obter a URL correta para baixar o arquivo de distribuição. Use ISCVERSION diretamente para nomear o arquivo de distribuição. Derivar <varname>DISTNAME</varname> a partir de <varname>PORTVERSION</varname> De tempos em tempos, o nome do arquivo de distribuição tem pouca ou nenhuma relação com a versão do software. No comms/kermit, apenas o último elemento da versão está presente no arquivo de distribuição: PORTNAME= kermit PORTVERSION= 9.0.304 CATEGORIES= comms ftp net MASTER_SITES= ftp://ftp.kermitproject.org/kermit/test/tar/ DISTNAME= cku${PORTVERSION:E}-dev20 O modificador :E make1 retorna o sufixo da variável, neste caso, 304. O arquivo de distribuição cku304-dev20.tar.gz é gerado corretamente. Caso Exótico 1 Às vezes, não há relação entre o nome do software, sua versão e o arquivo de distribuição no qual ele é distribuído. Do audio/libworkman: PORTNAME= libworkman PORTVERSION= 1.4 CATEGORIES= audio MASTER_SITES= LOCAL/jim DISTNAME= ${PORTNAME}-1999-06-20 Caso Exótico 2 No comms/librs232, o arquivo de distribuição não é versionado, portanto, DIST_SUBDIR é necessário: PORTNAME= librs232 PORTVERSION= 20160710 CATEGORIES= comms MASTER_SITES= http://www.teuniz.net/RS-232/ DISTNAME= RS-232 DIST_SUBDIR= ${PORTNAME}-${PORTVERSION} PKGNAMEPREFIX e PKGNAMESUFFIX não afetam o DISTNAME. Observe também que se WRKSRC for igual a ${WRKDIR}/${DISTNAME} enquanto o arquivo fonte original é nomeado para algo diferente de ${PORTNAME}-${PORTVERSION}${EXTRACT_SUFX}, deixe DISTNAME sozinho— definir apenas DISTFILES é mais fácil que ambos DISTNAME e WRKSRC (e possivelmente EXTRACT_SUFX). <varname>MASTER_SITES</varname> Grave a parte do diretório do FTP/HTTP-URL apontando para o tarball original em MASTER_SITES. Não esqueça a barra final (/)! A macro make irá tentar usar esta especificação para baixar o arquivo de distribuição com FETCH se não for possível encontrá-lo já no sistema. Recomenda-se que vários sites sejam incluídos nesta lista, de preferência em diferentes continentes. Isso irá proteger contra problemas de rede amplos. MASTER_SITES não deve estar em branco. Ele deve apontar para o site real que hospeda os arquivos de distribuição. Ele não pode apontar para web archives ou para os sites de cache dos arquivos de distribuição do FreeBSD. A única exceção a essa regra são ports que não possuem arquivos de distribuição. Por exemplo, meta-ports não possuem arquivos de distribuição, assim o MASTER_SITES não precisa ser definido. Usando Variáveis <varname>MASTER_SITE_<replaceable>*</replaceable></varname>​​ Abreviações de atalhos estão disponíveis para arquivos populares como o SourceForge (SOURCEFORGE), GNU (GNU), ou Perl CPAN (PERL_CPAN). MASTER_SITES pode usá-los diretamente: MASTER_SITES= GNU/make O antigo formato expandido ainda funciona, mas todos os ports foram convertidos para o formato compacto. O formato expandido se parece com isto: MASTER_SITES= ${MASTER_SITE_GNU} MASTER_SITE_SUBDIR= make Estes valores e variáveis ​​são definidos em Mk/bsd.sites.mk. Novas entradas são adicionadas com frequência, portanto, verifique a versão mais recente deste arquivo antes de enviar um port. Para qualquer variável MASTER_SITE_FOO , a versão abreviada FOO pode ser utilizada. Por exemplo, use: MASTER_SITES= FOO E se MASTER_SITE_SUBDIR for necessário, use isso: MASTER_SITES= FOO/bar Alguns nomes MASTER_SITE_* são bastante longos e, para facilitar o uso, foram definidos atalhos: Atalhos para Macros <varname>MASTER_SITE_<replaceable>*</replaceable></varname> Macro Atalho PERL_CPAN CPAN GITHUB GH GITHUB_CLOUD GHC LIBREOFFICE_DEV LODEV NETLIB NL RUBYGEMS RG SOURCEFORGE SF
Macros Mágicas de MASTER_SITES Várias macros mágicas existem para sites populares com uma estrutura de diretórios previsível. Para isso, basta usar a abreviação e o sistema escolherá um subdiretório automaticamente. Para um port nomeado Stardict, de versão 1.2.3 e hospedado no SourceForge, adicione esta linha: MASTER_SITES= SF Implica em um subdiretório chamado /project/stardict/stardict/1.2.3. Se o diretório estiver incorreto, ele poderá ser substituído: MASTER_SITES= SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION} Isso também pode ser escrito como MASTER_SITES= SF MASTER_SITE_SUBDIR= stardict/WyabdcRealPeopleTTS/${PORTVERSION} Macros Mágicas de <varname>MASTER_SITES</varname> Macro Subdiretório deduzido APACHE_COMMONS_BINARIES ${PORTNAME:S,commons-,,} APACHE_COMMONS_SOURCE ${PORTNAME:S,commons-,,} APACHE_JAKARTA ${PORTNAME:S,-,/,}/source BERLIOS ${PORTNAME:tl}.berlios CHEESESHOP source/${DISTNAME:C/(.).*/\1/}/${DISTNAME:C/(.*)-[0-9].*/\1/} CPAN ${PORTNAME:C/-.*//} DEBIAN pool/main/${PORTNAME:C/^((lib)?.).*$/\1/}/${PORTNAME} FARSIGHT ${PORTNAME} FESTIVAL ${PORTREVISION} GCC releases/${DISTNAME} GENTOO distfiles GIMP ${PORTNAME}/${PORTVERSION:R}/ GH ${GH_ACCOUNT}/${GH_PROJECT}/tar.gz/${GH_TAGNAME}?dummy=/ GHC ${GH_ACCOUNT}/${GH_PROJECT}/ GNOME sources/${PORTNAME}/${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/} GNU ${PORTNAME} GNUPG ${PORTNAME} GNU_ALPHA ${PORTNAME} HORDE ${PORTNAME} LODEV ${PORTNAME} MATE ${PORTVERSION:C/^([0-9]+\.[0-9]+).*/\1/} MOZDEV ${PORTNAME:tl} NL ${PORTNAME} QT archive/qt/${PORTVERSION:R} SAMBA ${PORTNAME} SAVANNAH ${PORTNAME:tl} SF ${PORTNAME:tl}/${PORTNAME:tl}/${PORTVERSION}
<varname>USE_GITHUB</varname> Se o arquivo de distribuição vier de um commit ou tag específico no GitHub para o qual não há arquivo lançado oficialmente, há uma maneira fácil de definir o DISTNAME e MASTER_SITES corretos automaticamente. Estas variáveis ​​estão disponíveis: <varname>USE_GITHUB</varname>Descrição Variável Descrição Padrão GH_ACCOUNT Nome da conta do usuário do GitHub que hospeda o projeto ${PORTNAME} GH_PROJECT Nome do projeto no GitHub ${PORTNAME} GH_TAGNAME Nome da tag para download (2.0.1, hash, ...) Usar o nome de uma branch aqui é errado. Também é possível usar o hash de um ID de commit para gerar um snapshot. ${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX} GH_SUBDIR Quando o software precisa que um arquivo de distribuição adicional seja extraído em ${WRKSRC}, esta variável pode ser usada. Veja os exemplos em para maiores informações. (none) GH_TUPLE GH_TUPLE permite colocar GH_ACCOUNT, GH_PROJECT, GH_TAGNAME e GH_SUBDIR em uma única variável. O formato é conta:projeto:tagname:grupo/subdiretório. O /subdiretório é opcional. Isso é útil quando mais de um projeto no GitHub precisa ser utilizado.
Não use GH_TUPLE para o arquivo de distribuição padrão, já que não tem nenhum padrão. Uso Simples de <varname>USE_GITHUB</varname> Ao tentar fazer um port para a versão 1.2.7 do pkg do usuário FreeBSD no github, em , O Makefile acabaria ficando assim (levemente simplificado para o exemplo): PORTNAME= pkg DISTVERSION= 1.2.7 USE_GITHUB= yes GH_ACCOUNT= freebsd MASTER_SITES será automaticamente definido como GH GHC e WRKSRC para ${WRKDIR}/pkg-1.2.7. Uso Mais Completo de <varname>USE_GITHUB</varname> Ao tentar fazer um port para uma versão de desenvolvimento do pkg do usuário FreeBSD no github, em , o Makefile acaba ficando assim (levemente simplificado para o exemplo): PORTNAME= pkg-devel DISTVERSION= 1.3.0.a.20140411 USE_GITHUB= yes GH_ACCOUNT= freebsd GH_PROJECT= pkg GH_TAGNAME= 6dbb17b MASTER_SITES será automaticamente definido para GH GHC e WRKSRC para ${WRKDIR}/pkg-6dbb17b. 20140411 é a data do commit referenciada em GH_TAGNAME, não a data em que é editado o Makefile, ou a data em que o commit é feito. Uso de <varname>USE_GITHUB</varname> com <varname>DISTVERSIONPREFIX</varname> De tempos em tempos, GH_TAGNAME é uma ligeira variação de DISTVERSION. Por exemplo, se a versão for 1.0.2, e a tag v1.0.2. Nesses casos, é possível usar DISTVERSIONPREFIX ou DISTVERSIONSUFFIX: PORTNAME= foo DISTVERSIONPREFIX= v DISTVERSION= 1.0.2 USE_GITHUB= yes GH_TAGNAME será automaticamente definido para v1.0.2, enquanto WRKSRC será mantido como ${WRKDIR} /foo-1.0.2. Usando <varname>USE_GITHUB</varname> Quando o Upstream Não Usa Versões Se nunca houve uma versão upstream, não invente uma como 0.1 ou 1.0. Crie o port com um DISTVERSION de gYYYYMMDD, onde g é para Git e YYYYMMDD representa a data em que o commit é referenciado em GH_TAGNAME. PORTNAME= bar DISTVERSION= g20140411 USE_GITHUB= yes GH_TAGNAME= c472d66b Isso cria um esquema de controle de versão que é incrementado com o tempo e que ainda é menor do que a versão 0 (veja para mais informações do pkg-version8): % pkg version -t g20140411 0 < Isso significa que não será necessário usar o PORTEPOCH caso o upstream decida lançar versões no futuro. Usando <varname>USE_GITHUB</varname> para Acessar um Commit Entre Duas Versões Se a versão atual do software usa uma tag Git, e o port precisa ser atualizado para uma versão mais recente e intermediária, sem uma tag, use git-describe1 para descobrir a versão a ser utilizada: % git describe --tags f0038b1 v0.7.3-14-gf0038b1 v0.7.3-14-gf0038b1pode ser dividido em três partes: v0.7.3 Este é a última tag Git que aparece no histórico de commits antes do commit solicitado. -14 Isso significa que o commit solicitado, f0038b1, é o 14º commit após a tag v0.7.3. -gf0038b1 O -g significa Git, e o f0038b1 é o commit hash referenciado. PORTNAME= bar DISTVERSIONPREFIX= v DISTVERSION= 0.7.3-14 DISTVERSIONSUFFIX= -gf0038b1 USE_GITHUB= yes Isso cria um esquema de versionamento que é incrementado com o tempo (bem, em cima de commits), e não entra em conflito com a criação de uma versão 0.7.4. (Veja para detalhes do pkg-version8): % pkg version -t 0.7.3 0.7.3.14 < % pkg version -t 0.7.3.14 0.7.4 < Se o commit solicitado é o mesmo que uma tag, uma descrição mais curta é mostrada por padrão. A versão mais longa é equivalente: % git describe --tags c66c71d v0.7.3 % git describe --tags --long c66c71d v0.7.3-0-gc66c71d Baixando Múltiplos Arquivos do GitHub O framework USE_GITHUB também suporta a obtenção de vários arquivos de distribuição de diferentes locais no GitHub. Ele funciona de uma forma muito semelhante ao - Ao buscar vários arquivos do GitHub, às vezes o arquivo de distribuição padrão não é buscado no GitHub. Para desabilitar a busca da distribuição padrão, defina: - - USE_GITHUB= nodefault - Vários valores são adicionados a GH_ACCOUNT, GH_PROJECT e GH_TAGNAME. Cada valor diferente é atribuído a um grupo. O valor principal pode não ter nenhum grupo ou grupo :DEFAULT. Um valor pode ser omitido se for o mesmo que o padrão listado em GH_TUPLE também pode ser usado quando há muitos arquivos de distribuição. Isso ajuda a manter as informações de conta, projeto, tagname e grupo no mesmo lugar. Para cada grupo, uma variável auxiliar ${WRKSRC_group} é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis ${WRKSRC_group} ​​podem ser usadas para mover diretórios durante o post-extract, ou para serem adicionadas em CONFIGURE_ARGS, ou o que for necessário para que o software seja compilado corretamente. A parte do :group deve ser usada para apenas um arquivo de distribuição. Ela é usado como uma chave única e usá-la mais de uma vez irá sobrescrever os valores anteriores. Como isso é apenas modificações de DISTFILES e MASTER_SITES, os nomes dos grupos devem obedecer às restrições de nomes de grupos descritas em + Ao buscar vários arquivos do GitHub, às vezes o arquivo de distribuição padrão não é buscado no GitHub. Para desabilitar a busca da distribuição padrão, defina: + + USE_GITHUB= nodefault + + + Ao utilizar USE_GITHUB=nodefault, o Makefile deve ter DISTFILES em seu bloco inicial. A definição deve ser: + + DISTFILES= ${DISTNAME}${EXTRACT_SUFX} + + Uso de <varname>USE_GITHUB</varname> com Vários Arquivos de Distribuição De tempos em tempos é necessário baixar mais de um arquivo de distribuição. Por exemplo, quando o repositório git do upstream usa submódulos. Isso pode ser feito facilmente usando grupos nas variáveis GH_*: PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_ACCOUNT= bar:icons,contrib GH_PROJECT= foo-icons:icons foo-contrib:contrib GH_TAGNAME= 1.0:icons fa579bc:contrib GH_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} Isso irá baixar três arquivos de distribuição do github. O padrão vem de foo/foo versão 1.0.2. O segundo, com o grupo icons, vem de bar/foo-icons versão 1.0. O terceiro vem de bar/foo-contrib e usa o commit do Gitfa579bc. Os arquivos de distribuição são nomeados foo-foo-1.0.2_GH0.tar.gz, bar-foo-icons-1.0_GH0.tar.gz e bar-foo-contrib-fa579bc_GH0.tar.gz. Todos os arquivos de distribuição são extraídos em ${WRKDIR} em seus respectivos subdiretórios. O arquivo padrão ainda é extraído em ${WRKSRC}, nesse caso, ${WRKDIR}/foo-1.0.2. Cada arquivo de distribuição adicional é extraído em ${WRKSRC_group}. Aqui, para o grupo icons, chamado de ${WRKSRC_icons}, será ${WRKDIR}/foo-icons-1.0. O arquivo com o grupo contrib é chamado de ${WRKSRC_contrib} e contém ${WRKDIR}/foo-contrib-fa579bc. O sistema de compilação do software espera encontrar os ícones em um subdiretório ext/icons em seus fontes, então GH_SUBDIR é usado. GH_SUBDIR garante que ext exista, mas não que ext/icons também exista. Então isso acontece: post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons Uso de <varname>USE_GITHUB</varname> com Vários Arquivos de Distribuição Usando <varname>GH_TUPLE</varname> Isto é funcionalmente equivalente a mas usando GH_TUPLE: PORTNAME= foo DISTVERSION= 1.0.2 USE_GITHUB= yes GH_TUPLE= bar:foo-icons:1.0:icons/ext/icons \ bar:foo-contrib:fa579bc:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} Agrupamento foi usado no exemplo anterior com bar:icons, contrib. Algumas informações redundantes estão presentes com GH_TUPLE porque o uso de agrupamento não é possível. Como Usar <varname>USE_GITHUB</varname> com Submodulos <application>Git</application>? Ports com o GitHub como um repositório upstream às vezes usam submódulos. Veja git-submodule1 para maiores informações. O problema com submódulos é que cada um é um repositório separado. Como tal, cada um deve ser buscado separadamente. Usando finances/moneymanagerex como exemplo, seu repositório GitHub é . Tem um arquivo .gitmodules na raiz. Este arquivo descreve todos os sub módulos usados ​​neste repositório e lista os repositórios adicionais necessários. Este arquivo irá dizer quais repositórios adicionais são necessários: [submodule "lib/wxsqlite3"] path = lib/wxsqlite3 url = https://github.com/utelle/wxsqlite3.git [submodule "3rd/mongoose"] path = 3rd/mongoose url = https://github.com/cesanta/mongoose.git [submodule "3rd/LuaGlue"] path = 3rd/LuaGlue url = https://github.com/moneymanagerex/LuaGlue.git [submodule "3rd/cgitemplate"] path = 3rd/cgitemplate url = https://github.com/moneymanagerex/html-template.git [...] A única informação que falta nesse arquivo é a hash ou tag de commit para usar na versão. Esta informação é encontrada após a clonagem do repositório: % git clone --recurse-submodules https://github.com/moneymanagerex/moneymanagerex.git Cloning into 'moneymanagerex'... remote: Counting objects: 32387, done. [...] Submodule '3rd/LuaGlue' (https://github.com/moneymanagerex/LuaGlue.git) registered for path '3rd/LuaGlue' Submodule '3rd/cgitemplate' (https://github.com/moneymanagerex/html-template.git) registered for path '3rd/cgitemplate' Submodule '3rd/mongoose' (https://github.com/cesanta/mongoose.git) registered for path '3rd/mongoose' Submodule 'lib/wxsqlite3' (https://github.com/utelle/wxsqlite3.git) registered for path 'lib/wxsqlite3' [...] Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/LuaGlue'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/cgitemplate'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/3rd/mongoose'... Cloning into '/home/mat/work/freebsd/ports/finance/moneymanagerex/moneymanagerex/lib/wxsqlite3'... [...] Submodule path '3rd/LuaGlue': checked out 'c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b' Submodule path '3rd/cgitemplate': checked out 'cd434eeeb35904ebcd3d718ba29c281a649b192c' Submodule path '3rd/mongoose': checked out '2140e5992ab9a3a9a34ce9a281abf57f00f95cda' Submodule path 'lib/wxsqlite3': checked out 'fb66eb230d8aed21dec273b38c7c054dcb7d6b51' [...] % cd moneymanagerex % git submodule status c51d11a247ee4d1e9817dfa2a8da8d9e2f97ae3b 3rd/LuaGlue (heads/master) cd434eeeb35904ebcd3d718ba29c281a649b192c 3rd/cgitemplate (cd434ee) 2140e5992ab9a3a9a34ce9a281abf57f00f95cda 3rd/mongoose (6.2-138-g2140e59) fb66eb230d8aed21dec273b38c7c054dcb7d6b51 lib/wxsqlite3 (v3.4.0) [...] Também pode ser encontrado no GitHub. Cada subdiretório que é um submódulo é mostrado como diretório @ hash, por exemplo,mongoose @ 2140e59. Embora a obtenção das informações pelo GitHub pareça mais fácil, as informações encontradas usando git submodule status fornecerá informações mais significativas. Por exemplo, o commit hash de lib/wxsqlite3 fb66eb2 corresponde a v3.4.0. Ambos podem ser usados, mas quando uma tag estiver disponível, use-a. Agora que todas as informações necessárias foram reunidas, o Makefile pode ser escrito (somente as linhas relacionadas ao GitHub são mostradas): PORTNAME= moneymanagerex DISTVERSIONPREFIX= v DISTVERSION= 1.3.0 USE_GITHUB= yes GH_TUPLE= utelle:wxsqlite3:v3.4.0:wxsqlite3/lib/wxsqlite3 \ moneymanagerex:LuaGlue:c51d11a:lua_glue/3rd/LuaGlue \ moneymanagerex:html-template:cd434ee:html_template/3rd/cgitemplate \ cesanta:mongoose:2140e59:mongoose/3rd/mongoose \ [...] <varname>USE_GITLAB</varname> Semelhante ao GitHub, se o arquivo de distribuição vier de gitlab.com ou se estiver hospedado com o software GitLab, essas variáveis ​​estão disponíveis para uso e talvez precisem ser definidas. <varname>USE_GITLAB</varname> Descrição Variável Descrição Padrão GL_SITE Nome do site que hospeda o projeto GitLab https://gitlab.com GL_ACCOUNT Nome da conta do usuário do GitLab hospedando o projeto ${PORTNAME} GL_PROJECT Nome do projeto em GitLab ${PORTNAME} GL_COMMIT O hash de commit para download. Deve ser o hash hex sha1 completo de 160 bits e 40 caracteres. Essa é uma variável obrigatória para GitLab. (none) GL_SUBDIR Quando o software precisa de um arquivo de distribuição adicional para ser extraído com ${WRKSRC}, esta variável pode ser usada. Veja os exemplos em para maiores informações. (none) GL_TUPLE GL_TUPLE permite colocar GL_SITE, GL_ACCOUNT, GL_PROJECT, GL_COMMIT, e GL_SUBDIR dentro de uma única variável. O formato é site:conta:projeto:commit:grupo/subdiretório. O site: e /subdiretório são opcionais. Isso ajuda quando é necessário baixar arquivos de mais de um projeto GitLab.
Uso Simples de <varname>USE_GITLAB</varname> Ao tentar fazer um port para a versão 1.14 do libsignon-glib do usuário accounts-sso do gitlab.com, em , O Makefile acabaria ficando assim para buscar os arquivos de distribuição: PORTNAME= libsignon-glib DISTVERSION= 1.14 USE_GITLAB= yes GL_ACCOUNT= accounts-sso GL_COMMIT= e90302e342bfd27bc8c9132ab9d0ea3d8723fd03 Ele terá automaticamente MASTER_SITES definido como gitlab.com e WRKSRC para ${WRKDIR}/libsignon-glib-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03-e90302e342bfd27bc8c9132ab9d0ea3d8723fd03. Uso Mais Completo de <varname>USE_GITLAB</varname> Um uso mais completo do exemplo acima é se o port não tiver controle de versão e foobar do usuário foo no projeto bar em um GitLab auto hospedado em https://gitlab.example.com, o Makefile acaba ficando assim para buscar os arquivos de distribuição: PORTNAME= foobar DISTVERSION= g20170906 USE_GITLAB= yes GL_SITE= https://gitlab.example.com GL_ACCOUNT= foo GL_PROJECT= bar GL_COMMIT= 9c1669ce60c3f4f5eb43df874d7314483fb3f8a6 Terá MASTER_SITES definido como "https://gitlab.example.com" e WRKSRC para ${WRKDIR}/bar-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6-9c1669ce60c3f4f5eb43df874d7314483fb3f8a6. 20170906 é a data do commit referenciada em GL_COMMIT, não a data em que o Makefile é editado, ou a data em que o commit para a árvore de ports do FreeBSD é feito. O protocolo, porta e webroot do GL_SITE podem ser modificados na mesma variável. Baixando Múltiplos Arquivos do <application>GitLab</application> O framework USE_GITLAB também suporta a busca de vários arquivos de distribuição de diferentes locais de GitLab e sites hospedados no GitLab. Ele funciona de uma forma muito semelhante ao e . - Ao buscar vários arquivos usando GitLab, às vezes, o arquivo de distribuição padrão não é obtido de um GitLab. Para desativar a busca do arquivo de distribuição padrão, defina: - - USE_GITLAB= nodefault - Vários valores são adicionados a GL_SITE, GL_ACCOUNT, GL_PROJECT e GL_COMMIT. Cada valor diferente é atribuído a um grupo. . GL_TUPLE também pode ser usado quando há muitos arquivos de distribuição. Isso ajuda a manter as informações de site, conta, projeto, commit e grupo no mesmo local. Para cada grupo, uma variável auxiliar ${WRKSRC_group} é criada, contendo o diretório no qual o arquivo foi extraído. As variáveis ${WRKSRC_group} ​​podem ser usadas para mover diretórios durante o post-extract, ou para serem adicionadas em CONFIGURE_ARGS, ou o que for necessário para que o software seja compilado corretamente. A parte do :group deve ser usada para apenas um arquivo de distribuição. Ela é usado como uma chave única e usá-la mais de uma vez irá sobrescrever os valores anteriores. Como isso é apenas modificações de DISTFILES e MASTER_SITES, os nomes dos grupos devem obedecer às restrições de nomes de grupos descritas em + Ao buscar vários arquivos usando GitLab, às vezes, o arquivo de distribuição padrão não é obtido de um GitLab. Para desativar a busca do arquivo de distribuição padrão, defina: + + USE_GITLAB= nodefault + + + Ao utilizar USE_GITLAB=nodefault, o Makefile deve ter DISTFILES em seu bloco inicial. A definição deve ser: + + DISTFILES= ${DISTNAME}${EXTRACT_SUFX} + + + Uso de <varname>USE_GITLAB</varname> com Vários Arquivos de Distribuição De tempos em tempos, é necessário buscar mais de um arquivo de distribuição. Por exemplo, quando o repositório git do upstream usa submódulos. Isso pode ser feito facilmente usando grupos nas variáveis GL_*: PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_SITE= https://gitlab.example.com:9434/gitlab:icons GL_ACCOUNT= bar:icons,contrib GL_PROJECT= foo-icons:icons foo-contrib:contrib GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b ae7368cab1ca7ca754b38d49da064df87968ffe4:icons 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib GL_SUBDIR= ext/icons:icons CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} Isso irá buscar dois arquivos de distribuição do gitlab.com e um de gitlab.example.com hospedado com GitLab. O padrão vem de https://gitlab.com/foo/foo e o commit é c189207a55da45305c884fe2b50e086fcad4724b. O segundo, com o grupo icons, vem de https://gitlab.example.com:9434/gitlab/bar/foo-icons e o commit é ae7368cab1ca7ca754b38d49da064df87968ffe4. O terceiro vem de https://gitlab.com/bar/foo-contrib e o commit é 9e4dd76ad9b38f33fdb417a4c01935958d5acd2a. Os arquivos de distribuição são nomeados foo-foo-c189207a55da45305c884fe2b50e086fcad4724b_GL0.tar.gz, bar-foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4_GL0.tar.gz e bar-foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a_GL0.tar.gz. Todos os arquivos de distribuição são extraídos no ${WRKDIR} em seus respectivos subdiretórios. O arquivo padrão ainda é extraído no ${WRKSRC}, nesse caso, ${WRKDIR}/foo-c189207a55da45305c884fe2b50e086fcad4724b-c189207a55da45305c884fe2b50e086fcad4724b. Cada arquivo de distribuição adicional é extraído em ${WRKSRC_group}. Aqui, para o grupo icons, é chamado ${WRKSRC_icons} e contém ${WRKDIR}/foo-icons-ae7368cab1ca7ca754b38d49da064df87968ffe4-ae7368cab1ca7ca754b38d49da064df87968ffe4. O arquivo com o grupo contrib é chamado ${WRKSRC_contrib} e contém ${WRKDIR}/foo-contrib-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a-9e4dd76ad9b38f33fdb417a4c01935958d5acd2a. O sistema de compilação do software espera encontrar os ícones em um subdiretório ext/icons em seus fontes, então GL_SUBDIR é usado.GL_SUBDIR garante que ext existe, mas não que ext/icons também exista. Então isso acontece: post-extract: @${MV} ${WRKSRC_icons} ${WRKSRC}/ext/icons Uso de <varname>USE_GITLAB</varname> com Vários Arquivos de Distribuição Usando <varname>GL_TUPLE</varname> Isto é funcionalmente equivalente a mas usando GL_TUPLE: PORTNAME= foo DISTVERSION= 1.0.2 USE_GITLAB= yes GL_COMMIT= c189207a55da45305c884fe2b50e086fcad4724b GL_TUPLE= https://gitlab.example.com:9434/gitlab:bar:foo-icons:ae7368cab1ca7ca754b38d49da064df87968ffe4:icons/ext/icons \ bar:foo-contrib:9e4dd76ad9b38f33fdb417a4c01935958d5acd2a:contrib CONFIGURE_ARGS= --with-contrib=${WRKSRC_contrib} Agrupamento foi usado no exemplo anterior com bar:icons,contrib. Algumas informações redundantes estão presentes com GL_TUPLE porque o uso de agrupamento não é possível. <varname>EXTRACT_SUFX</varname> Se houver um arquivo de distribuição e ele usar um sufixo diferente para indicar o mecanismo de compactação, defina EXTRACT_SUFX. Por exemplo, se o arquivo de distribuição foi nomeado foo.tar.gzip em vez do mais comum foo.tar.gz, escreva: DISTNAME= foo EXTRACT_SUFX= .tar.gzip O USES=tar[:xxx], USES=lha ou USES=zip define automaticamente EXTRACT_SUFX com as extensões de arquivo mais comuns, conforme necessário, consulte para mais detalhes. Se nenhum destes estiver definido, o EXTRACT_SUFX padrão é .tar.gz. Como EXTRACT_SUFX é usado apenas em DISTFILES, apenas defina um deles.. <varname>DISTFILES</varname> Às vezes os nomes dos arquivos a serem baixados não têm semelhança com o nome do port. Por exemplo, pode ser chamado source.tar.gz ou similar. Em outros casos, o código-fonte do aplicativo pode estar em vários arquivos diferentes, e todos eles devem ser baixados. Se este for o caso, defina DISTFILES para ser uma lista separada por espaços de todos os arquivos que devem ser baixados. DISTFILES= source1.tar.gz source2.tar.gz Se não for definido explicitamente, o DISTFILES padrão é ${DISTNAME}${EXTRACT_SUFX}. <varname>EXTRACT_ONLY</varname> Se apenas alguns dos DISTFILES devem ser extraídos— por exemplo, um deles é o código-fonte, enquanto outro é um documento não compactado - liste os nomes dos arquivos que devem ser extraídos em EXTRACT_ONLY. DISTFILES= source.tar.gz manual.html EXTRACT_ONLY= source.tar.gz Quando nenhum dos DISTFILES precisam ser descompactados, deixe vazio o EXTRACT_ONLY. EXTRACT_ONLY= <varname>PATCHFILES</varname> Se o port requer alguns patches adicionais que estão disponíveis por FTP ou HTTP, defina PATCHFILES para os nomes dos arquivos e PATCH_SITES para a URL do diretório que os contém (o formato é o mesmo do MASTER_SITES). Se o patch não for relativo ao inicio da árvore do código fonte (isto é, WRKSRC) porque contém alguns pathnames extras, defina PATCH_DIST_STRIP adequadamente. Por exemplo, se todos os pathnames no patch tiverem um foozolix-1.0 / extra na frente dos nomes dos arquivos, então defina PATCH_DIST_STRIP=-p1. Não se preocupe se os patches estiverem compactados; eles serão descompactados automaticamente se os nomes dos arquivos terminarem com .Z, .gz, .bz2 ou .xz. Se o patch for distribuído com alguns outros arquivos, como documentação, em um arquivo compactado, o uso de PATCHFILES não será possível. Se for esse o caso, adicione o nome e a localização do arquivo do patch em DISTFILES e MASTER_SITES. Então, use EXTRA_PATCHES para apontar para esses arquivos e o bsd.port.mk irá aplicá-los automaticamente. Em particular, não copie os arquivos de patch em ${PATCHDIR}. Esse diretório pode não ter permissão de escrita. Se houver vários patches e eles precisarem de valores mistos para o parâmetro strip, ele poderá ser adicionado ao lado do nome do patch em PATCHFILES, por exemplo: PATCHFILES= patch1 patch2:-p1 Isto não entra em conflito com o recurso de agrupamento de sites principais, adicionando um grupo também funciona: PATCHFILES= patch2:-p1:source2 O arquivo será extraído junto com o arquivo de código fonte, então não há necessidade de explicitamente extraí-lo se ele for um arquivo compactado normal. Tome cuidado extra para não sobrescrever algo que já existe nesse diretório caso faça a extração manualmente. Também não se esqueça de adicionar um comando para remover o patch copiado no target pre-clean. Múltiplos Arquivos de Distribuição ou Patches de Vários Locais (Considere isto como um tópico avançado; a princípio, aqueles que são novos neste documento podem desejar pular esta seção). Esta seção contém informações sobre o mecanismo de busca conhecido como MASTER_SITES:n e MASTER_SITES_NN. Vamos nos referir a este mecanismo como MASTER_SITES:n Um pouco de background primeiro. O OpenBSD tem um ótimo recurso dentro do DISTFILES e PATCHFILES que permite que arquivos e pacthes sejam pós fixados com identificadores :n. Aqui, n pode ser qualquer palavra que contenha [0-9a-zA-Z_] e signifique uma designação de grupo. Por exemplo: DISTFILES= alpha:0 beta:1 No OpenBSD, arquivo de distribuição alpha será associado com a variável MASTER_SITES0 em vez da nossa comum MASTER_SITES e beta com MASTER_SITES1. Esta é uma característica muito interessante que pode diminuir a busca sem fim pelo site de download correto. Apenas imagine 2 arquivos em DISTFILES e 20 sites em MASTER_SITES, os sites são extremamente lentos e beta é hospedado em todas as entradas do MASTER_SITES e alfa só pode ser encontrado no 20º site. Seria um desperdício checar todos eles se o mantenedor soubesse isso de antemão, não seria? Não é um bom começo para aquele lindo fim de semana! Agora que você já tem uma ideia, imagine mais DISTFILES e mais MASTER_SITES. Certamente nosso distfiles survey meister irá ser apreciado pelo alívio nas conexões de rede que isso trará. Nas próximas seções, as informações seguirão a implementação do FreeBSD desta idéia. Nós melhoramos um pouco o conceito do OpenBSD. Os nomes dos grupos não podem ter traços neles (-), na verdade, eles não podem ter nenhum caractere fora do range [a-zA-Z0-9_]. Isso porque, enquanto make1 está ok com nomes de variáveis ​​contendo traços, sh1não. Informação Simplificada Esta seção explica como preparar rapidamente a busca de vários arquivos de distribuição e patches de diferentes sites e subdiretórios. Descrevemos aqui um caso de uso de MASTER_SITES:n. Isso será suficiente para a maioria dos cenários. Informações mais detalhadas estão disponíveis em . Alguns aplicativos consistem em vários arquivos de distribuição que devem ser baixados de vários sites diferentes. Por exemplo, Ghostscript consiste no núcleo do programa e, em seguida, um grande número de arquivos de driver que são usados ​​dependendo da impressora do usuário. Alguns desses arquivos de driver são fornecidos com o núcleo, mas muitos outros devem ser baixados de uma variedade de sites diferentes. Para suportar isso, cada entrada no DISTFILES pode ser seguida por dois pontos e um nome de grupo. Cada site listado em MASTER_SITES é então seguido por dois pontos, e o grupo que indica quais arquivos de distribuição são baixados deste site. Por exemplo, considere um aplicativo com a divisão do código fonte em duas partes, source1.tar.gz e source2.tar.gz, que deve ser baixado de dois sites diferentes. O Makefile do port incluiria linhas como Uso Simplificado de <literal>MASTER_SITES:n</literal> com Um Arquivo Por Site MASTER_SITES= ftp://ftp1.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 Vários arquivos de distribuição podem ter o mesmo grupo. Continuando o exemplo anterior, suponha que houvesse um terceiro distfile, source3.tar.gz, que é baixado do ftp.example2.com. O Makefile seria então escrito como . Uso Simplificado de <literal>MASTER_SITES:n</literal> com Mais de Um Arquivo Por Site MASTER_SITES= ftp://ftp.example.com/:source1 \ http://www.example.com/:source2 DISTFILES= source1.tar.gz:source1 \ source2.tar.gz:source2 \ source3.tar.gz:source2 Informação Detalhada Ok, então o exemplo anterior não refletiu as necessidades do novo port? Nesta seção vamos explicar em detalhes como o mecanismo de busca avançado MASTER_SITES:n funciona e como ele pode ser usado. Elementos podem ser pós-fixados com :n onde n é [^:,]+, isso é, n poderia conceitualmente ser qualquer string alfanumérica, mas vamos limitá-lo a [a-zA-Z_][0-9a-zA-Z_]+ por enquanto. Além disso, a verificação de strings é case sensitive, ou seja, n é diferente de N. No entanto, essas palavras não podem ser usadas para finalidades de pós-fixação, pois elas produzem um significado especial: default, all e ALL (estes são usados ​​internamente no item ). Além disso, DEFAULT é uma palavra de propósito especial (verifique o item ). Elementos pós-fixados com :n pertence ao grupo n, :m pertence ao grupo m e assim por diante. Elementos que não estão pós-fixados são desagrupados, todos eles pertencem ao grupo especial DEFAULT. Quaisquer elementos pós-fixados com DEFAULT estão apenas sendo redundantes, a menos que um elemento pertença a ambos DEFAULT e outros grupos ao mesmo tempo (verifique o item ). Esses exemplos são equivalentes, mas o primeiro é o preferido: MASTER_SITES= alpha MASTER_SITES= alpha:DEFAULT Grupos não são exclusivos, um elemento pode pertencer a vários grupos diferentes ao mesmo tempo e um grupo pode ter vários elementos diferentes ou nenhum. Quando um elemento pertence a vários grupos ao mesmo tempo, use uma vírgula (, ). Em vez de repetir isso várias vezes, cada vez com uma pós-fixação diferente, podemos listar vários grupos de uma vez em uma única pós-fixação. Por exemplo, :m,n,o marca um elemento que pertence ao grupo m, n e o. Todos esses exemplos são equivalentes, mas o último é o preferido: MASTER_SITES= alpha alpha:SOME_SITE MASTER_SITES= alpha:DEFAULT alpha:SOME_SITE MASTER_SITES= alpha:SOME_SITE,DEFAULT MASTER_SITES= alpha:DEFAULT,SOME_SITE Todos os sites dentro de um determinado grupo são ordernados de acordo com MASTER_SORT_AWK. Todos os grupos dentro de MASTER_SITES e PATCH_SITES são ordenados também. A semântica de grupo pode ser usada em qualquer uma das variáveis MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR, PATCH_SITE_SUBDIR, DISTFILES e PATCHFILES de acordo com esta sintaxe: Todos elementos MASTER_SITES, PATCH_SITES, MASTER_SITE_SUBDIR e PATCH_SITE_SUBDIR devem ser terminados com o caractere barra /. Se algum elemento pertencer a algum grupo, o grupo de pós-fixação :n deve vir logo após o terminador /. O mecanismo MASTER_SITES:n depende da existência do terminador / para evitar confundir elementos onde um :n é uma parte válida do elemento com ocorrências em que :n denota grupo n. Para fins de compatibilidade, uma vez que o terminador / não for necessário antes em ambos elementos MASTER_SITE_SUBDIR e PATCH_SITE_SUBDIR, se o caractere precedente imediato da pós-fixação não for / então :n será considerada uma parte válida do elemento em vez de uma pós-fixação de grupo, mesmo que um elemento n seja pós-fixado. Veja ambos e Uso Detalhado de <literal>MASTER_SITES:n</literal> no <varname>MASTER_SITE_SUBDIR</varname> MASTER_SITE_SUBDIR= old:n new/:NEW Diretórios dentro do grupo DEFAULT -> old:n Diretórios dentro do grupo NEW -> new Uso Detalhado de <literal>MASTER_SITES:n</literal> com Vírgula, Vários Arquivos, Vários Sites e Vários Subdiretórios MASTER_SITES= http://site1/%SUBDIR%/http://site2/:DEFAULT \ http://site3/:group3 http://site4/:group4 \ http://site5/:group5 http://site6/:group6 \ http://site7/:DEFAULT,group6 \ http://site8/%SUBDIR%/:group6,group7 \ http://site9/:group8 DISTFILES= file1 file2:DEFAULT file3:group3 \ file4:group4,group5,group6 file5:grouping \ file6:group7 MASTER_SITE_SUBDIR= directory-trial:1 directory-n/:groupn \ directory-one/:group6,DEFAULT \ directory O exemplo anterior resulta em uma busca detalhada. Os sites são listados na ordem exata em que serão usados. arquivo1 será obtido a partir de MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP arquivo2 será baixado exatamente como o arquivo1 já que ambos pertencem ao mesmo grupo MASTER_SITE_OVERRIDE http://site1/directory-trial:1/ http://site1/directory-one/ http://site1/directory/ http://site2/ http://site7/ MASTER_SITE_BACKUP arquivo3 será obtido a partir de MASTER_SITE_OVERRIDE http://site3/ MASTER_SITE_BACKUP arquivo4 será obtido a partir de MASTER_SITE_OVERRIDE http://site4/ http://site5/ http://site6/ http://site7/ http://site8/directory-one/ MASTER_SITE_BACKUP arquivo5 será obtido a partir de MASTER_SITE_OVERRIDE MASTER_SITE_BACKUP file6 será obtido a partir de MASTER_SITE_OVERRIDE http://site8/ MASTER_SITE_BACKUP Como posso agrupar uma das macros especiais de bsd.sites.mk, por exemplo, SourceForge (SF)? Isso foi simplificado o máximo possível. Veja . Uso Detalhado de <literal>MASTER_SITES:n</literal> com SourceForge (<literal>SF</literal>) MASTER_SITES= http://site1/SF/something/1.0:sourceforge,TEST DISTFILES= something.tar.gz:sourceforge something.tar.gz será obtido por todos os sites do SourceForge. Como eu uso isso com PATCH*? Todos os exemplos foram feitos com MASTER* mas eles funcionam exatamente da mesma forma com PATCH* como pode ser visto em . Uso Simplificado de <literal>MASTER_SITES:n</literal> com <varname>PATCH_SITES</varname> PATCH_SITES= http://site1/ http://site2/:test PATCHFILES= patch1:test O que Muda para os Ports? O que Não Funciona? Todos os ports atuais permanecem os mesmos. A feature MASTER_SITES:n só é ativada se houver elementos pós-fixados com :n como elementos de acordo com as regras de sintaxe acima, especialmente como mostrado no item . Os targets de port permanecem os mesmos: checksum, makesum, patch, configure, build, etc. Com as exceções óbvias de do-fetch, fetch-list, master-sites e patch-sites. do-fetch: implementa o novo agrupamento pós-fixado DISTFILES e PATCHFILES com seus elementos de grupo correspondentes dentro de ambos MASTER_SITES e PATCH_SITES que usam elementos de grupo correspondentes dentro de ambos MASTER_SITE_SUBDIR e PATCH_SITE_SUBDIR. Verifique . fetch-list: funciona como o antigo fetch-list, com a exceção de que faz agrupamentos exatamente como o do-fetch. master-sites e patch-sites: (incompatível com versões mais antigas) somente retorna os elementos do grupo DEFAULT; na verdade, eles executam os targets master-sites-default e patch-sites-default respectivamente. Além disso, usar o target master-sites-all ou patch-sites-all é o preferido para verificar diretamente MASTER_SITES ou PATCH_SITES. Além disso, não é garantido que a checagem direta funcione em versões futuras. Veja para obter mais informações sobre esses novos tagets de port. Novos Targets de Port Existem targets master-sites-n e patch-sites-n que listarão os elementos do respectivo grupo n dentro de MASTER_SITES e PATCH_SITES respectivamente. Por exemplo, ambos master-sites-DEFAULT e patch-sites-DEFAULT retornarão os elementos do grupo DEFAULT, master-sites-test e patch-sites-test do grupo test. Há novos targets master-sites-all e patch-sites-all que fazem o trabalho dos antigos master-sites e patch-sites. Eles retornam os elementos de todos os grupos como se todos pertencessem ao mesmo grupo, com a ressalva de que lista tantos MASTER_SITE_BACKUP e MASTER_SITE_OVERRIDE como existem grupos definidos dentro de qualquer DISTFILES ou PATCHFILES; respectivamente para master-sites-all e patch-sites-all. <varname>DIST_SUBDIR</varname> Não deixe o /usr/ports/distfiles bagunçado. Se um port exigir que muitos arquivos sejam baixados, ou que contenha um arquivo que tenha um nome que possa entrar em conflito com outros ports (por exemplo, Makefile), defina DIST_SUBDIR com o nome do port (${PORTNAME} ou ${PKGNAMEPREFIX}${PORTNAME}). Isso vai mudar o DISTDIR do padrão /usr/ports/distfiles para /usr/ports/distfiles/${DIST_SUBDIR},e assim, será colocado tudo o que é necessário para o port nesse subdiretório. Ele também examinará o subdiretório com o mesmo nome no site principal de backup em http://distcache.FreeBSD.org (Configurar o DISTDIR explicitamente no Makefile não fará isso funcionar, então por favor use DIST_SUBDIR. Isso não afeta o MASTER_SITES definido no Makefile. <varname>MAINTAINER</varname> Defina seu endereço de email aqui. Por favor. :-) Apenas um único endereço sem a parte de comentário é permitido como um valor para MAINTAINER. O formato usado é user@hostname.domain. Por favor, não inclua nenhum texto descritivo, como um nome nesta entrada. Isso confunde a infraestrutura do Ports e a maioria das ferramentas que a usam. O mantenedor é responsável por manter o port atualizado e garantir que elo funcione corretamente. Para obter uma descrição detalhada das responsabilidades de um mantenedor de port, consulte O desafio para os mantenedores de port. Um mantenedor se voluntaria para manter um port em bom estado de funcionamento. Os mantenedores têm a responsabilidade primária por seus ports, mas não possuem propriedade exclusiva. Os ports existem para o benefício da comunidade e, na realidade, pertencem à comunidade. O que isso significa é que outras pessoas além do mantenedor, também podem fazer alterações em um port. Grandes mudanças na Coleção de Ports podem exigir mudanças em muitos ports. A Equipe de Gerenciamento do Ports do FreeBSD ou membros de outras equipes podem modificar ports para corrigir problemas de dependência ou outros problemas, como um bump de versão para uma atualização de biblioteca compartilhada. Alguns tipos de correções tem aprovação implícita da Equipe de Gerenciamento de Ports portmgr@FreeBSD.org, permitindo que qualquer committer conserte essas categorias de problemas em qualquer port. Essas correções não precisam de aprovação do mantenedor. A aprovação implícita não se aplica a ports que são mantidos por times como autotools@FreeBSD.org, x11@FreeBSD.org, gnome@FreeBSD.org ou kde@FreeBSD.org. Esses times usam repositórios externos e podem ter alterações que entrariam em conflito com mudanças que normalmente seriam abrangidas pela aprovação implícita. Aprovação implícita para a maioria dos ports se aplicam para correções como mudanças de infraestrutura, trivialidades e correções testadas de compilação e execução. A lista atual está disponibilizada em Seção Ports do Guia dos Committers. Outras alterações no port serão enviadas ao mantenedor para revisão e aprovação antes de se fazer o commit. Se o mantenedor não responder a uma solicitação de atualização após duas semanas (excluindo os principais feriados), isso será considerado como timeout do mantenedor, e a atualização poderá ser feita sem a aprovação explícita do mesmo. Se o mantenedor não responder dentro de três meses, ou se houver três timeouts consecutivos, então o mantenedor é considerado ausente, e todas os seus ports podem ser atribuídos de volta para à comunidade. Exceções para isso são quaisquer ports mantidos pela Equipe de Gerenciamento de Ports portmgr@FreeBSD.org ou pela Equipe de Oficias de Segurança security-officer@FreeBSD.org. Nenhum commit não autorizado pode ser feito em ports mantidos por esses grupos. Reservamo-nos o direito de modificar as submissões do mantenedor para melhor adequar as políticas e os estilos existentes da Coleção de Ports sem aprovação explicita do remetente ou do mantenedor. Além disso, grandes alterações de infraestrutura podem resultar na modificação de um port sem o consentimento do mantenedor. Estes tipos de alterações nunca irão afetar a funcionalidade do port. A Equipe de Gerenciamento de Ports portmgr@FreeBSD.org reserva o direito de revogar ou substituir a propriedade de mantenedor de qualquer pessoa por qualquer motivo, e a Equipe de Oficiais de Segurança security-officer@FreeBSD.org reserva o direito de revogar ou substituir a propriedade de mantenedor por razões de segurança. <varname>COMMENT</varname> O comentário é uma descrição de uma linha de um port mostrada por pkg info. Por favor, siga estas regras ao compor: A string COMMENT deve ter 70 caracteres ou menos. Não inclua o nome do pacote ou o número da versão do software. O comentário deve começar com uma letra maiúscula e terminar sem um ponto final. Não comece com um artigo indefinido (isto é, A ou Um). Capitalize nomes como Apache, JavaScript ou Perl. Use uma vírgula serial para listas de palavras: "verde, vermelho, e azul." Verifique erros de ortografia. Aqui está um exemplo: COMMENT= Cat chasing a mouse all over the screen A variável COMMENT vem depois da variável MAINTAINER no Makefile. Licenças Cada port deve documentar a licença sob a qual está disponível. Se não for uma licença aprovada pelo OSI, também deve documentar quaisquer restrições à redistribuição. <varname>LICENSE</varname> Um nome abreviado para a licença ou licenças se mais de uma licença for aplicada. Se for uma das licenças listadas no , apenas as variáveis LICENSE_FILE e LICENSE_DISTFILES podem ser definidas. Se esta for uma licença que não tenha sido definida na infraestrutura de ports (veja ), LICENSE_PERMS e LICENSE_NAME devem ser definidos, juntamente com LICENSE_FILE ou LICENSE_TEXT. LICENSE_DISTFILES e LICENSE_GROUPS também podem ser definidos, mas não é necessário. As licenças pré-definidas são mostradas em . A lista atual está sempre disponível em Mk/bsd.licenses.db.mk. Uso Mais Simples, Licenças Predefinidas Quando o README de algum software diz This software is under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. mas não fornece o arquivo de licença, use isto: LICENSE= LGPL21+ Quando o software fornece o arquivo de licença, use isto: LICENSE= LGPL21+ LICENSE_FILE= ${WRKSRC}/COPYING Para as licenças predefinidas, as permissões padrão são dist-mirror dist-sell pkg-mirror pkg-sell auto-accept. Lista de Licenças Predefinidas Nome Curto Nome Grupo Permissões AGPLv3 GNU Affero General Public License version 3 FSF GPL OSI (padrão) AGPLv3+ GNU Affero General Public License version 3 (ou maior) FSF GPL OSI (padrão) APACHE10 Apache License 1.0 FSF (padrão) APACHE11 Apache License 1.1 FSF OSI (padrão) APACHE20 Apache License 2.0 FSF OSI (padrão) ART10 Artistic License version 1.0 OSI (padrão) ART20 Artistic License version 2.0 FSF GPL OSI (padrão) ARTPERL10 Artistic License (perl) version 1.0 OSI (padrão) BSD BSD license Generic Version (deprecated) FSF OSI COPYFREE (padrão) BSD2CLAUSE BSD 2-clause "Simplified" License FSF OSI COPYFREE (padrão) BSD3CLAUSE BSD 3-clause "New" or "Revised" License FSF OSI COPYFREE (padrão) BSD4CLAUSE BSD 4-clause "Original" or "Old" License FSF (padrão) BSL Boost Software License FSF OSI COPYFREE (padrão) CC-BY-1.0 Creative Commons Attribution 1.0 (padrão) CC-BY-2.0 Creative Commons Attribution 2.0 (padrão) CC-BY-2.5 Creative Commons Attribution 2.5 (padrão) CC-BY-3.0 Creative Commons Attribution 3.0 (padrão) CC-BY-4.0 Creative Commons Attribution 4.0 (padrão) CC-BY-NC-1.0 Creative Commons Attribution Non Commercial 1.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-2.0 Creative Commons Attribution Non Commercial 2.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-2.5 Creative Commons Attribution Non Commercial 2.5 dist-mirror pkg-mirror auto-accept CC-BY-NC-3.0 Creative Commons Attribution Non Commercial 3.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-4.0 Creative Commons Attribution Non Commercial 4.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-ND-1.0 Creative Commons Attribution Non Commercial No Derivatives 1.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-ND-2.0 Creative Commons Attribution Non Commercial No Derivatives 2.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-ND-2.5 Creative Commons Attribution Non Commercial No Derivatives 2.5 dist-mirror pkg-mirror auto-accept CC-BY-NC-ND-3.0 Creative Commons Attribution Non Commercial No Derivatives 3.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-ND-4.0 Creative Commons Attribution Non Commercial No Derivatives 4.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-SA-1.0 Creative Commons Attribution Non Commercial Share Alike 1.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-SA-2.0 Creative Commons Attribution Non Commercial Share Alike 2.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-SA-2.5 Creative Commons Attribution Non Commercial Share Alike 2.5 dist-mirror pkg-mirror auto-accept CC-BY-NC-SA-3.0 Creative Commons Attribution Non Commercial Share Alike 3.0 dist-mirror pkg-mirror auto-accept CC-BY-NC-SA-4.0 Creative Commons Attribution Non Commercial Share Alike 4.0 dist-mirror pkg-mirror auto-accept CC-BY-ND-1.0 Creative Commons Attribution No Derivatives 1.0 (padrão) CC-BY-ND-2.0 Creative Commons Attribution No Derivatives 2.0 (padrão) CC-BY-ND-2.5 Creative Commons Attribution No Derivatives 2.5 (padrão) CC-BY-ND-3.0 Creative Commons Attribution No Derivatives 3.0 (padrão) CC-BY-ND-4.0 Creative Commons Attribution No Derivatives 4.0 (padrão) CC-BY-SA-1.0 Creative Commons Attribution Share Alike 1.0 (padrão) CC-BY-SA-2.0 Creative Commons Attribution Compartilhar Alike 2.0 (padrão) CC-BY-SA-2.5 Creative Commons Attribution Share Alike 2.5 (padrão) CC-BY-SA-3.0 Creative Commons Attribution Share Alike 3.0 (padrão) CC-BY-SA-4.0 Creative Commons Attribution Share Alike 4.0 (padrão) CC0-1.0 Creative Commons Zero v1.0 Universal FSF GPL COPYFREE (padrão) CDDL Common Development and Distribution License FSF OSI (padrão) CPAL-1.0 Common Public Attribution License FSF OSI (padrão) ClArtistic Clarified Artistic License FSF GPL OSI (padrão) EPL Eclipse Public License FSF OSI (padrão) GFDL GNU Free Documentation License FSF (padrão) GMGPL GNAT Modified General Public License FSF GPL OSI (padrão) GPLv1 GNU General Public License version 1 FSF GPL OSI (padrão) GPLv1+ GNU General Public License version 1 (or later) FSF GPL OSI (padrão) GPLv2 GNU General Public License version 2 FSF GPL OSI (padrão) GPLv2+ GNU General Public License version 2 (or later) FSF GPL OSI (padrão) GPLv3 GNU General Public License version 3 FSF GPL OSI (padrão) GPLv3+ GNU General Public License version 3 (or later) FSF GPL OSI (padrão) GPLv3RLE GNU GPL version 3 Runtime Library Exception FSF GPL OSI (padrão) GPLv3RLE+ GNU GPL version 3 Runtime Library Exception (or later) FSF GPL OSI (padrão) ISCL Internet Systems Consortium License FSF GPL OSI COPYFREE (padrão) LGPL20 GNU Library General Public License version 2.0 FSF GPL OSI (padrão) LGPL20+ GNU Library General Public License version 2.0 (or later) FSF GPL OSI (padrão) LGPL21 GNU Lesser General Public License version 2.1 FSF GPL OSI (padrão) LGPL21+ GNU Lesser General Public License version 2.1 (or later) FSF GPL OSI (padrão) LGPL3 GNU Lesser General Public License version 3 FSF GPL OSI (padrão) LGPL3+ GNU Lesser General Public License version 3 (or later) FSF GPL OSI (padrão) LPPL10 LaTeX Project Public License version 1.0 FSF OSI dist-mirror dist-sell LPPL11 LaTeX Project Public License version 1.1 FSF OSI dist-mirror dist-sell LPPL12 LaTeX Project Public License version 1.2 FSF OSI dist-mirror dist-sell LPPL13 LaTeX Project Public License version 1.3 FSF OSI dist-mirror dist-sell LPPL13a LaTeX Project Public License version 1.3a FSF OSI dist-mirror dist-sell LPPL13b LaTeX Project Public License version 1.3b FSF OSI dist-mirror dist-sell LPPL13c LaTeX Project Public License version 1.3c FSF OSI dist-mirror dist-sell MIT MIT license / X11 license COPYFREE FSF GPL OSI (padrão) MPL10 Mozilla Public License version 1.0 FSF OSI (padrão) MPL11 Mozilla Public License version 1.1 FSF OSI (padrão) MPL20 Mozilla Public License version 2.0 FSF OSI (padrão) NCSA University of Illinois/NCSA Open Source License COPYFREE FSF GPL OSI (padrão) NONE No license specified none OFL10 SIL Open Font License version 1.0 (http://scripts.sil.org/OFL) FONTS (padrão) OFL11 SIL Open Font License version 1.1 (http://scripts.sil.org/OFL) FONTS (padrão) OWL Open Works License (owl.apotheon.org) COPYFREE (padrão) OpenSSL Licença OpenSSL FSF (padrão) PD Public Domain GPL COPYFREE (padrão) PHP202 PHP License version 2.02 FSF OSI (padrão) PHP30 PHP License version 3.0 FSF OSI (padrão) PHP301 PHP License versão 3.01 FSF OSI (padrão) PSFL Python Software Foundation License FSF GPL OSI (padrão) PostgreSQL PostgreSQL Licence FSF GPL OSI COPYFREE (padrão) RUBY Ruby License FSF (padrão) UNLICENSE The Unlicense COPYFREE FSF GPL (padrão) WTFPL Do What the Fuck You Want To Public License version 2 GPL FSF COPYFREE (padrão) WTFPL1 Do What the Fuck You Want To Public License version 1 GPL FSF COPYFREE (padrão) ZLIB zlib License GPL FSF OSI (padrão) ZPL21 Zope Public License version 2.1 GPL OSI (padrão)
<varname>LICENSE_PERMS</varname> e <varname>LICENSE_PERMS_<replaceable>NAME</replaceable></varname> Permissões. Use none se vazio. Lista de Permissões de Licença dist-mirror A redistribuição dos arquivos de distribuição é permitida. Os arquivos de distribuição serão adicionados ao FreeBSD CDN MASTER_SITE_BACKUP. no-dist-mirror A redistribuição dos arquivos de distribuição é proibida. Isso é equivalente a RESTRICT. Os arquivos de distribuição não serão adicionados ao FreeBSD CDN MASTER_SITE_BACKUP. dist-sell A venda de arquivos de distribuição é permitida. Os arquivos de distribuição estarão presentes nas imagens do instalador. no-dist-sell A venda de arquivos de distribuição é proibida. Isso é equivalente a NO_CDROM. pkg-mirror É permitida a redistribuição gratuita do pacote. O pacote será distribuído na CDN de pacotes do FreeBSD https://pkg.freebsd.org/. no-pkg-mirror É proibida a redistribuição gratuita do pacote. Equivalente à definir NO_PACKAGE. O pacote não será distribuído a partir da CDN de pacotes do FreeBSD https://pkg.freebsd.org/. pkg-sell A venda do pacote é permitida. O pacote estará presente nas imagens do instalador. no-pkg-sell A venda de pacotes é proibida. Isso é equivalente a definir NO_CDROM. O pacote não estará presente nas imagens do instalador. auto-accept A licença é aceita por padrão. Os prompts para aceitar uma licença não são exibidos a menos que o usuário tenha definido LICENSES_ASK. Use isto, a menos que a licença indique que o usuário deve aceitar os termos da licença. no-auto-accept A licença não é aceita por padrão. O usuário sempre será solicitado a confirmar a aceitação desta licença. Isso deve ser usado se a licença declarar que o usuário deve aceitar seus termos. Quando ambos permission e no-permission estiverem presentes o no-permission vai cancelar a permission. Quando permission não estiver presente, é considerado uma no-permission. Algumas permissões que estiverem faltando, impedirão que um port (e todos os ports dependendo dele) sejam utilizados pelos usuários do pacote: Um port sem a permissão auto-accept nunca será compilado e todos os ports dependendo dele serão ignorados. Um port sem a permissão pkg-mirror será removido, assim como todos os ports que dependam dele, isso depois da compilação e então eles nunca serão distribuídos. Licença Não Padrão Leia os termos da licença e traduza-os usando as permissões disponíveis. LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= Esse programa NÃO é de domínio publico.\ pode ser distribuído livremente para propósitos não comerciais apenas,\ e NÃO HÁ GARANTIA PARA ESSE PROGRAMA. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept Licenças Padrão e Não Padrão Leia os termos da licença e expresse-os usando as permissões disponíveis. Em caso de dúvida, peça orientação na lista de discussão de ports do FreeBSD. LICENSE= WARSOW GPLv2 LICENSE_COMB= multi LICENSE_NAME_WARSOW= Warsow Content License LICENSE_FILE_WARSOW= ${WRKSRC}/docs/license.txt LICENSE_PERMS_WARSOW= dist-mirror pkg-mirror auto-accept Quando as permissões das licenças GPLv2 e UNKNOWN são misturadas, o port termina com dist-mirror dist-sell pkg-mirror pkg-sell auto-accept dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept. O no-permissions cancela as permissions. A lista resultante de permissões é dist-mirror pkg-mirror auto-accept. Os arquivos de distribuição e os pacotes não estarão disponíveis nas imagens do instalador. <varname>LICENSE_GROUPS</varname> e <varname>LICENSE_GROUPS_<replaceable>NAME</replaceable></varname> Grupos que a licença pertence. Lista de Grupos de Licenças Predefinidas FSF Aprovada pela Free Software Foundation, veja FSF Licensing & Compliance Team. GPL Compatível com GPL OSI Aprovado pelo OSI, veja a pagina Open Source Initiative Open Source Licenses. COPYFREE Segue a Copyfree Standard Definition, consulte a pagina Copyfree Licenses. FONTS Licenças de fonte <varname>LICENSE_NAME</varname> e <varname>LICENSE_NAME_<replaceable>NAME</replaceable></varname> Nome completo da licença. <varname>LICENSE_NAME</varname> LICENSE= UNRAR LICENSE_NAME= UnRAR License LICENSE_FILE= ${WRKSRC}/license.txt LICENSE_PERMS= dist-mirror dist-sell pkg-mirror pkg-sell auto-accept <varname>LICENSE_FILE</varname> e <varname>LICENSE_FILE_<replaceable>NOME</replaceable></varname> Caminho completo para o arquivo que contém o texto da licença, geralmente ${WRKSRC}/some/file. Se o arquivo não estiver no distfile e seu conteúdo for muito longo para ser colocado em LICENSE_TEXT, insira o texto em um novo arquivo em ${FILESDIR}. <varname>LICENSE_FILE</varname> LICENSE= GPLv3+ LICENSE_FILE= ${WRKSRC}/COPYING <varname>LICENSE_TEXT</varname> e <varname>LICENSE_TEXT_<replaceable>NAME</replaceable></varname> Texto para usar como uma licença. Útil quando a licença não está nos arquivos de distribuição e seu texto é curto. <varname>LICENSE_TEXT</varname> LICENSE= UNKNOWN LICENSE_NAME= unknown LICENSE_TEXT= This program is NOT in public domain.\ It can be freely distributed for non-commercial purposes only,\ and THERE IS NO WARRANTY FOR THIS PROGRAM. LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept <varname>LICENSE_DISTFILES</varname> e <varname>LICENSE_DISTFILES_<replaceable>NAME</replaceable></varname> Os arquivos de distribuição aos quais as licenças se aplicam. O padrão é para todos os arquivos de distribuição. <varname>LICENSE_DISTFILES</varname> Usado quando os arquivos de distribuição não possuem a mesma licença. Por exemplo, um possui uma licença de código e outro possui alguns trabalhos de arte que não podem ser redistribuídos: MASTER_SITES= SF/some-game DISTFILES= ${DISTNAME}${EXTRACT_SUFX} artwork.zip LICENSE= BSD3CLAUSE ARTWORK LICENSE_COMB= dual LICENSE_NAME_ARTWORK= The game artwork license LICENSE_TEXT_ARTWORK= The README says that the files cannot be redistributed LICENSE_PERMS_ARTWORK= pkg-mirror pkg-sell auto-accept LICENSE_DISTFILES_BSD3CLAUSE= ${DISTNAME}${EXTRACT_SUFX} LICENSE_DISTFILES_ARTWORK= artwork.zip <varname>LICENSE_COMB</varname> Defina como multi se todas as licenças se aplicarem. Defina como dual se qualquer uma das licenças se aplica. O padrão é definido para single. Licenças Duplas Quando um port diz This software may be distributed under the GNU General Public License or the Artistic License>, isso significa que qualquer licença pode ser usada. Use isto: LICENSE= ART10 GPLv1 LICENSE_COMB= dual Se os arquivos de licença forem fornecidos, use assim: LICENSE= ART10 GPLv1 LICENSE_COMB= dual LICENSE_FILE_ART10= ${WRKSRC}/Artistic LICENSE_FILE_GPLv1= ${WRKSRC}/Copying Múltiplas Licenças Quando parte de um port tem uma licença, e outra parte tem uma licença diferente, use multi: LICENSE= GPLv2 LGPL21+ LICENSE_COMB= multi <varname>PORTSCOUT</varname> Portscout é um utilitário de verificação de distfile automatizado para a Coleção de Ports do FreeBSD, descrito em detalhes em . PORTSCOUT define condições especiais dentro das quais o scanner distfile do Portscout é restrito. Situações em que o PORTSCOUT é configurado: Quando distfiles precisam ser ignorados, seja para versões específicas, ou para pequenas revisões específicas. Por exemplo, para excluir a versão 8.2 das verificações de versão de distfile porque é conhecido por estar quebrado, adicione: PORTSCOUT= ignore:8.2 Quando versões específicas ou revisões maiores e menores específicas de um distfile devem ser verificadas. Por exemplo, se somente a versão 0.6.4 deve ser monitorado porque versões mais recentes têm problemas de compatibilidade com o FreeBSD, adicione: PORTSCOUT= limit:^0\.6\.4 Quando os URLs que listam as versões disponíveis diferem dos URLs de download. Por exemplo, para limitar as verificações de versão do arquivo distfile à página de download para o port databases/pgtune, adicione: PORTSCOUT= site:http://pgfoundry.org/frs/?group_id=1000416 Dependências Muitos ports dependem de outros ports. Esta é uma característica muito conveniente da maioria dos sistemas operacionais Unix-like, incluindo FreeBSD. Vários ports podem compartilhar uma dependência comum, ao invés de agrupar essa dependência com cada port ou pacote que precisa dela. Há sete variáveis ​​que podem ser usadas para garantir que todos os bits necessários estejam na máquina do usuário. Existem também algumas variáveis ​​de dependência pré-suportadas para casos comuns, além de algumas outras para controlar o comportamento das dependências. <varname>LIB_DEPENDS</varname> Esta variável especifica as bibliotecas compartilhadas das quais este port depende. É uma lista de tuplas lib:dir onde lib é o nome da biblioteca compartilhada, dir é o diretório no qual encontrá-lo, caso não esteja disponível. Por exemplo, LIB_DEPENDS= libjpeg.so:graphics/jpeg irá verificar se há uma biblioteca jpeg compartilhada com qualquer versão no subdiretório graphics/jpeg da árvore de ports para compilar e instalar se não for encontrado. A dependência é verificada duas vezes, uma vez dentro do target build e depois dentro do target install. Além disso, o nome da dependência é colocado no pacote para que o pkg-install (veja pkg-install8) a instale automaticamente se a mesma não estiver no sistema do usuário. <varname>RUN_DEPENDS</varname> Esta variável especifica arquivos executáveis ​​ou arquivos para os quais este port depende durante o tempo de execução. É uma lista de tuplas path:dir:target onde path é o nome do executável ou arquivo,dir é o diretório no qual encontrá-lo, caso não esteja disponível, e o target é o target para chamar nesse diretório. E se o path começar com uma barra (/), ele será tratado como um arquivo e sua existência é testada com test -e; caso contrário, é assumido como um executável e which -s é usado para determinar se o programa existe no caminho de pesquisa. Por exemplo, RUN_DEPENDS= ${LOCALBASE}/news/bin/innd:news/inn \ xmlcatmgr:textproc/xmlcatmgr irá verificar se o arquivo ou diretório /usr/local/news/bin/innd existe, e compilar e instalá-lo a partir do subdiretório news/inn da árvore de ports, caso não seja encontrado. Ele também verá se um executável chamado xmlcatmgr está no caminho de pesquisa em textproc/xmlcatmgr para compilar e instalar se não for encontrado. Nesse caso, innd é na verdade um executável; se um executável estiver em um local que não deve estar no caminho de pesquisa, use o nome do caminho completo. A pesquisa oficial PATH usado no cluster de construção de ports é /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin A dependência é verificada a partir do target install. Além disso, o nome da dependência é colocado no pacote para que o pkg-install (veja pkg-install8) a instale automaticamente se a mesma não estiver no sistema do usuário. A parte target pode ser omitida se for igual a DEPENDS_TARGET. Uma situação bastante comum é quando RUN_DEPENDS é literalmente o mesmo que BUILD_DEPENDS, especialmente se o software portado é escrito em uma linguagem de script ou se requer o mesmo ambiente de compilação e tempo de execução. Neste caso, é tentador e intuitivo atribuir diretamente um ao outro: RUN_DEPENDS= ${BUILD_DEPENDS} No entanto, essa atribuição pode poluir as dependências de tempo de execução com entradas não definidas no BUILD_DEPENDS original do port. Isso acontece por causa de uma avaliação preguiçosa de atribuição de variáveis do make1. Considere um Makefile com USES_*, que são processados ​​por ports/Mk/bsd.*.mk para aumentar as dependências iniciais de compilação. Por exemplo, USES=gmake adiciona devel/gmake para BUILD_DEPENDS. Para evitar que essas dependências adicionais poluam RUN_DEPENDS, crie outra variável com o conteúdo atual de BUILD_DEPENDS e atribua-a para ambos BUILD_DEPENDS e RUN_DEPENDS: MY_DEPENDS= some:devel/some \ other:lang/other BUILD_DEPENDS= ${MY_DEPENDS} RUN_DEPENDS= ${MY_DEPENDS} Não use := para atribuir BUILD_DEPENDS para RUN_DEPENDS ou vice-versa. Todas as variáveis ​​são expandidas imediatamente, o que é exatamente a coisa errada a fazer e quase sempre um fracasso. <varname>BUILD_DEPENDS</varname> Esta variável especifica executáveis ​​ou arquivos que este port requer para ser compilado. Como RUN_DEPENDS, ela é uma lista de tuplas path:dir:target. Por exemplo, BUILD_DEPENDS= unzip:archivers/unzip irá procurar por um executável chamado unzip, e ir para o subdiretório archivers/unzip da árvore de ports para compilar e instalar se não for encontrado. build aqui significa tudo, desde a extração até a compilação. A dependência é verificada a partir do target extract. A parte do target pode ser omitida se for igual a DEPENDS_TARGET <varname>FETCH_DEPENDS</varname> Esta variável especifica executáveis ​​ou arquivos que este port requer para fazer os downloads. Como os dois anteriores, é uma lista de tuplas path:dir:target. Por exemplo, FETCH_DEPENDS= ncftp2:net/ncftp2 irá procurar por um executável chamado ncftp2 e ir para o subdiretório net/ncftp2 da árvore de ports para compilar e instalar se não for encontrado. A dependência é verificada a partir do target fetch. A parte target pode ser omitida se for igual a DEPENDS_TARGET. <varname>EXTRACT_DEPENDS</varname> Esta variável especifica executáveis ​​ou arquivos que este port requer para extração. Como no anterior, é uma lista de tuplas path:dir:target. Por exemplo, EXTRACT_DEPENDS= unzip:archivers/unzip irá procurar por um executável chamado unzip, e ir para o subdiretório archivers/unzip da árvore de ports para compilar e instalar se não for encontrado. A dependência é verificada a partir do target extract. A parte target pode ser omitida se for igual a DEPENDS_TARGET. Use esta variável somente se a extração ainda não funcionar (o padrão usa tar) e não funciona com USES=tar, USES=lha ou USES=zip descrito em . <varname>PATCH_DEPENDS</varname> Esta variável especifica executáveis ​​ou arquivos que este port requer para aplicar patches. Como no anterior, é uma lista de path:dir:target. Por exemplo, PATCH_DEPENDS= ${NONEXISTENT}:java/jfc:extract vai descer para o subdiretório java/jfc da árvore de ports para extraí-lo. A dependência é verificada a partir do target patch. A parte target pode ser omitida se for igual a DEPENDS_TARGET. <varname>USES</varname> Parâmetros podem ser adicionados para definir diferentes recursos e dependências usados ​​pelo port. Eles são especificados adicionando esta linha ao Makefile: USES= feature[:arguments] Para a lista completa de valores, por favor veja o . USES não pode ser atribuído após a inclusão de bsd.port.pre.mk. <varname>USE_<replaceable>*</replaceable></varname> Diversas variáveis ​​existem para definir dependências comuns compartilhadas por muitos ports. O uso é opcional, mas ajuda a reduzir a verbosidade dos Makefiles de port . Cada um deles é denominado como USES_*. Essas variáveis ​​podem ser usadas apenas no Makefile do port e ports/Mk/bsd.*.mk. Elas não são destinadas a opções configuráveis ​​pelo usuário - use PORT_OPTIONS para esse propósito. É sempre incorreto definir qualquer USE_* dentro de /etc/make.conf. Por exemplo, definindo USE_GCC=X.Y (onde XY é o número da versão) adicionaria uma dependência do gccXY para cada port, incluindo lang/gccXY em si! <varname>USE_<replaceable>*</replaceable></varname> Variável Significa USE_GCC O port requer GCC (gcc ou g++) para compilar. Alguns ports precisam de qualquer versão do GCC, algumas exigem versões modernas e recentes. Normalmente, é configurado para qualquer (neste caso, o GCC da base seria usado em versões do FreeBSD que ainda o possuem, ou o port lang/gcc seria instalado quando o compilador C/C++ padrão for o Clang); ou yes (significa usar sempre GCC estável e moderno do port lang/gcc). A versão exata também pode ser especificada, com um valor como 4.7. A versão mínima exigida pode ser especificada como 4.6+. O GCC do sistema base é usado quando satisfaz a versão solicitada, caso contrário, um compilador apropriado é compilado a partir do port, e CC e CXX são ajustados em conformidade. USE_GCC irá registrar uma dependência de tempo de compilação e uma de tempo de execução.
Variáveis ​​relacionadas ao gmake e configure são descritos em , enquanto autoconf, automake e libtool são descritos em . Variáveis relacionadas ao Perl ​são descritas em . Variáveis ​​X11 são listadas em . lida com o GNOME e com variáveis ​​relacionadas ao KDE. documenta variáveis ​​Java, enquanto contém informações sobre Apache, PHP e módulos PEAR. Python é discutido em , e Ruby em . fornece variáveis ​​usadas para aplicações SDL e, finalmente, contém informações sobre o Xfce. Versão Mínima de uma Dependência Uma versão mínima de uma dependência pode ser especificada em qualquer *_DEPENDS, exceto LIB_DEPENDS, usando esta sintaxe: p5-Spiffy>=0.26:devel/p5-Spiffy O primeiro campo contém um nome de pacote dependente, que deve corresponder à entrada no banco de dados de pacotes, um sinal de comparação e uma versão do pacote. A dependência é satisfeita se o p5-Spiffy-0.26 ou mais recente estiver instalado na máquina. Notas sobre Dependências Como mencionado acima, o target padrão para chamar quando uma dependência é necessária é o DEPENDS_TARGET. Seu padrão é o install. Esta é uma variável de usuário; nunca é definido em um Makefile de port. Se o port precisar de uma maneira especial de lidar com uma dependência, use a parte :target de *_DEPENDS em vez de redefinir DEPENDS_TARGET. Quando rodar make clean, as dependências de port também são limpas automaticamente. Se isso não for desejável, defina NOCLEANDEPENDS no ambiente. Isto pode ser particularmente desejável se o port tiver algo que demore muito tempo para recompilar em sua lista de dependências, como o KDE, o GNOME ou o Mozilla. Para depender de outro port incondicionalmente, use a variável ${NONEXISTENT} no primeiro campo do BUILD_DEPENDS ou RUN_DEPENDS. Use isto somente quando o código fonte do outro port for necessário. Tempo de compilação pode ser economizado especificando o target também. Por exemplo BUILD_DEPENDS= ${NONEXISTENT}:graphics/jpeg:extract sempre descerá para o port jpeg e extrai-lo. Dependências Circulares são Fatais Não insira nenhuma dependência circular na árvore de ports! A tecnologia de compilação de ports não tolera dependências circulares. Se uma for inserida, alguém, em algum lugar do mundo, terá sua instalação do FreeBSD quebrada quase que imediatamente, e muitos outros rapidamente terão o mesmo problema. Estes erros podem ser realmente difíceis de serem detectados. Em caso de dúvida, antes de fazer qualquer alteração, certifique-se de executar: cd /usr/ports; make index. Esse processo pode ser muito lento em máquinas mais antigas, mas pode evitar dor de cabeça para um grande número de pessoas, incluindo você. Problemas Causados ​​por Dependências Automáticas Dependências devem ser declaradas explicitamente ou usando o framework OPTIONS. Usar outros métodos, como a detecção automática, dificulta a indexação, o que causa problemas para o gerenciamento de ports e pacotes. Declaração Errada de uma Dependência Opcional .include <bsd.port.pre.mk> .if exists(${LOCALBASE}/bin/foo) LIB_DEPENDS= libbar.so:foo/bar .endif O problema em tentar adicionar dependências automaticamente é que os arquivos e configurações fora de um port individual podem ser alterados a qualquer momento. Por exemplo: um índice é construído, depois um lote de ports é instalado. Mas um dos ports instala o arquivo testado. O índice então fica incorreto, porque um port instalado inesperadamente tem uma nova dependência. O índice ainda pode estar errado mesmo após a recriação, se outros ports também determinarem a necessidade de dependências com base na existência de outros arquivos. Declaração Correta de uma Dependência Opcional OPTIONS_DEFINE= BAR BAR_DESC= Calling cellphones via bar BAR_LIB_DEPENDS= libbar.so:foo/bar Testar variáveis ​​de opções é o método correto. Ele não causará inconsistências no índice de um lote de ports, desde que as opções tenham sido definidas antes da construção do índice. Scripts simples podem ser usados ​​para automatizar a compilação, instalação e atualização desses ports e seus pacotes. Ports Slaves e <varname>MASTERDIR</varname> Se o port precisar criar versões ligeiramente diferentes de pacotes fazendo com que uma variável (por exemplo, resolução ou tamanho de papel) assuma valores diferentes, crie um subdiretório por pacote para facilitar aos usuários a visualização do que fazer, mas tente compartilhar o máximo possível de arquivos entre os ports. Normalmente, usando variáveis ​​inteligentemente, apenas um Makefile bem curto será necessário em todos, exceto em um dos diretórios. No Makefile solitário, use MASTERDIR para especificar o diretório onde o restante dos arquivos estão. Além disso, use uma variável como parte de PKGNAMESUFFIX para que os pacotes tenham nomes diferentes. Isso será melhor demonstrado por um exemplo. Isso é parte de print/pkfonts300/Makefile; PORTNAME= pkfonts${RESOLUTION} PORTVERSION= 1.0 DISTFILES= pk${RESOLUTION}.tar.gz PLIST= ${PKGDIR}/pkg-plist.${RESOLUTION} .if !defined(RESOLUTION) RESOLUTION= 300 .else .if ${RESOLUTION} != 118 && ${RESOLUTION} != 240 && \ ${RESOLUTION} != 300 && ${RESOLUTION} != 360 && \ ${RESOLUTION} != 400 && ${RESOLUTION} != 600 .BEGIN: @${ECHO_MSG} "Error: invalid value for RESOLUTION: \"${RESOLUTION}\"" @${ECHO_MSG} "Possible values are: 118, 240, 300, 360, 400 and 600." @${FALSE} .endif .endif print/pkfonts300 também tem todos os patches, arquivos de pacotes, etc. Rodando make nele, será assumido o valor padrão para a resolução (300) e o port será compilado normalmente. Quanto às outras resoluções, este é o print/pkfonts360/Makefile completo: RESOLUTION= 360 MASTERDIR= ${.CURDIR}/../pkfonts300 .include "${MASTERDIR}/Makefile" (print/pkfonts118/Makefile, print/pkfonts600/Makefile, e todos os outros são semelhantes). A definição de MASTERDIR diz ao bsd.port.mk que o conjunto regular de subdiretórios como FILESDIR e SCRIPTDIR podem ser encontrados em pkfonts300. A linha RESOLUTION=360 irá substituir a linha RESOLUTION=300 em pkfonts300/Makefile e o port será compilado com a resolução definida para 360. Páginas de Manual Se o port instala a sua árvore de manuais em outro lugar diferente de PREFIX, use MANDIRS para especificar esses diretórios. Note que os arquivos correspondentes às páginas de manual devem ser colocados no pkg-plist junto com o resto dos arquivos. O propósito do MANDIRS é ativar a compactação automática de páginas de manual, portanto, os nomes dos arquivos são sufixados com .gz. Arquivos de Informação Se o pacote precisar instalar arquivos de informações GNU, liste-os na variável INFO (sem o sufixo .info), uma entrada por documento. Presume-se que esses arquivos estejam instalados em PREFIX/INFO_PATH. Mude INFO_PATH se o pacote usa um local diferente. Contudo, isto não é recomendado. Essas entradas contêm apenas o caminho relativo para PREFIX/INFO_PATH. Por exemplo, lang/gcc34 instala arquivos de informações em PREFIX/INFO_PATH/gcc34 e INFO será algo assim: INFO= gcc34/cpp gcc34/cppinternals gcc34/g77 ... O código apropriado de instalação/desinstalação será automaticamente adicionado ao arquivo pkg-plist temporário antes do registro do pacote. Opções do Makefile Muitas aplicações podem ser compiladas com configurações opcionais ou diferentes. Exemplos podem ser a escolha de linguagem natural (humana), GUI versus linha de comando ou qual tipo de banco de dados será suportado. Os usuários podem precisar de uma configuração diferente do padrão, portanto o sistema de ports fornece ganchos em que o autor do port pode usar para controlar qual variante será compilada. Suportar essas opções corretamente fará com que os usuários fiquem felizes, e efetivamente forneça dois ou mais ports pelo preço de um. <varname>OPTIONS</varname> Background OPTIONS_* fornece ao usuário que está instalando o port uma caixa de diálogo mostrando as opções disponíveis e, em seguida, salva essas opções em ${PORT_DBDIR}/${OPTIONS_NAME}/options. Na próxima vez que o port for compilado, as opções serão reutilizadas. O padrão de PORT_DBDIR é /var/db/ports. OPTIONS_NAME é a origem do port com um underline como o separador de espaço, por exemplo, dns/bind99 será dns_bind99. Quando o usuário executa make config (ou executa make build pela primeira vez), o framework verifica ${PORT_DBDIR}/${OPTIONS_NAME}/options. Se esse arquivo não existir, os valores de OPTIONS_* são usados ​​e uma caixa de diálogo é exibida onde as opções podem ser ativadas ou desativadas. Então as options são salvas e as variáveis ​​configuradas são utilizadas ao compilar o port. Se uma nova versão do port adicionar novas OPTIONS, a caixa de diálogo será apresentada ao usuário, já preenchido com os valores salvos das antigas OPTIONS. make showconfig mostra a configuração salva. Use make rmconfig para remover a configuração salva. Sintaxe OPTIONS_DEFINE contém uma lista de OPTIONS para serem utilizadas. Elas são independentes umas das outras e não são agrupadas: OPTIONS_DEFINE= OPT1 OPT2 Uma vez definido, as OPTIONS são descritas (opcionalmente, mas fortemente recomendado): OPT1_DESC= Describe OPT1 OPT2_DESC= Describe OPT2 OPT3_DESC= Describe OPT3 OPT4_DESC= Describe OPT4 OPT5_DESC= Describe OPT5 OPT6_DESC= Describe OPT6 ports/Mk/bsd.options.desc.mk possui descrições para muitas OPTIONS comuns. Geralmente são úteis, mas podem ser substituas se a descrição for insuficiente para o port. Ao descrever as opções, visualize-as da perspectiva do usuário: Qual funcionalidade ela muda? e Por que eu iria querer habilitar ela? Não repita apenas o nome. Por exemplo, descrever a opção NLS como incluir suporte NLS não ajuda o usuário, que já pode ver o nome da opção, mas pode não saber o que isso significa. Descrevendo-a como Suporte a idiomas nativos por meio de utilitários gettext é muito mais útil. Os nomes das opções são sempre em letras maiúsculas. Não podem estar misturadas ou apenas em minúsculo. OPTIONS podem ser agrupadas como opções radio, onde apenas uma escolha de cada grupo é permitida: OPTIONS_SINGLE= SG1 OPTIONS_SINGLE_SG1= OPT3 OPT4 Deve estar sempre selecionada uma de cada OPTIONS_SINGLE para as opções serem válidas. Uma opção de cada grupo deve ser adicionada a OPTIONS_DEFAULT. OPTIONS podem ser agrupadas como opções radio, onde nenhuma ou apenas uma escolha de cada grupo é permitida: OPTIONS_RADIO= RG1 OPTIONS_RADIO_RG1= OPT7 OPT8 OPTIONS também pode ser agrupadas como listas de múltipla-escolha, onde pelo menos uma opção deve estar habilitada: OPTIONS_MULTI= MG1 OPTIONS_MULTI_MG1= OPT5 OPT6 OPTIONS também pode ser agrupadas como listas de múltipla-escolha, onde nenhuma ou qualquer opção pode ser ativada: OPTIONS_GROUP= GG1 OPTIONS_GROUP_GG1= OPT9 OPT10 OPTIONS são desativadas por padrão, a menos que estejam listadas em OPTIONS_DEFAULT: OPTIONS_DEFAULT= OPT1 OPT3 OPT6 Definições de OPTIONS devem aparecer antes da inclusão de bsd.port.options.mk. Valores de PORT_OPTIONS só podem ser testados após a inclusão de bsd.port.options.mk. Inclusão de bsd.port.pre.mk pode ser usado também, e ainda é amplamente usado em ports escritos antes da introdução de bsd.port.options.mk. Mas esteja ciente de que algumas variáveis não funcionarão como esperado após a inclusão de bsd.port.pre.mk, tipicamente algumas flags USE_*. Uso Simples de <varname>OPTIONS</varname> OPTIONS_DEFINE= FOO BAR OPTIONS_DEFAULT=FOO FOO_DESC= Option foo support BAR_DESC= Feature bar support # Will add --with-foo / --without-foo FOO_CONFIGURE_WITH= foo BAR_RUN_DEPENDS= bar:bar/bar .include <bsd.port.mk> Verificar <varname>OPTIONS</varname> Desmacadas .if ! ${PORT_OPTIONS:MEXAMPLES} CONFIGURE_ARGS+=--without-examples .endif O formato acima não é recomendado. O método preferido é usar um configure knob para realmente ativar e desativar o recurso coincidindo com a opção: # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples Uso Prático de <varname>OPTIONS</varname> OPTIONS_DEFINE= EXAMPLES OPTIONS_DEFAULT= PGSQL LDAP SSL OPTIONS_SINGLE= BACKEND OPTIONS_SINGLE_BACKEND= MYSQL PGSQL BDB OPTIONS_MULTI= AUTH OPTIONS_MULTI_AUTH= LDAP PAM SSL EXAMPLES_DESC= Install extra examples MYSQL_DESC= Use MySQL as backend PGSQL_DESC= Use PostgreSQL as backend BDB_DESC= Use Berkeley DB as backend LDAP_DESC= Build with LDAP authentication support PAM_DESC= Build with PAM support SSL_DESC= Build with OpenSSL support # Will add USE_PGSQL=yes PGSQL_USE= pgsql=yes # Will add --enable-postgres / --disable-postgres PGSQL_CONFIGURE_ENABLE= postgres ICU_LIB_DEPENDS= libicuuc.so:devel/icu # Will add --with-examples / --without-examples EXAMPLES_CONFIGURE_WITH= examples # Check other OPTIONS .include <bsd.port.mk> Opções Padrão Essas opções estão sempre ativadas por padrão. DOCS — build and install documentation. NLS — Native Language Support. EXAMPLES — build and install examples. IPV6 — IPv6 protocol support. Não há necessidade de adicioná-las em OPTIONS_DEFAULT. Para ativá-las e mostra-las na caixa de diálogo de seleção de opções, elas devem ser adicionadas em OPTIONS_DEFINE. Feature de Ativação Automática Ao usar um script configure GNU, fique de olho em quais recursos opcionais são ativados por detecção automática. Desative explicitamente os recursos opcionais que não são necessários, adicionando --without-xxx ou --disable-xxx em CONFIGURE_ARGS. Manipulação Incorreta de uma Opção .if ${PORT_OPTIONS:MFOO} LIB_DEPENDS+= libfoo.so:devel/foo CONFIGURE_ARGS+= --enable-foo .endif No exemplo acima, imagine que uma biblioteca libfoo está instalada no sistema. O usuário não quer que este aplicativo use libfoo, então ele desabilitou a opção na caixa de diálogo do make config. Mas o script configure do aplicativo detecta a biblioteca presente no sistema e inclui seu suporte no executável resultante. Agora, quando o usuário decide remover libfoo do sistema, o sistema de ports não protesta (nenhuma dependência de libfoo foi registrada), e então o aplicativo quebra. Manuseio Correto de uma Opção FOO_LIB_DEPENDS= libfoo.so:devel/foo # Will add --enable-foo / --disable-foo FOO_CONFIGURE_ENABLE= foo Sob algumas circunstâncias, a sintaxe condicional abreviada pode causar problemas com construções complexas. Os erros são geralmente Malformed conditional, e uma sintaxe alternativa pode ser usada. .if !empty(VARIABLE:MVALUE) como uma alternativa para .if ${VARIABLE:MVALUE} Assistentes de Opções Existem algumas macros para ajudar a simplificar valores condicionais que diferem com base nas opções definidas. Para facilitar o acesso, é fornecida uma lista abrangente: PLIST_SUB, SUB_LIST Para geração automática de %%OPT%% e %%NO_OPT%%, veja . Para uso mais complexo, veja . CONFIGURE_ARGS Para --enable-x e --disable-x, veja . Para --with-x e --without-x, veja . Para todos os outros casos, veja . CMAKE_ARGS Para argumentos que são booleanos (on, off, true, false, 0, 1) veja . Para todos os outros casos, veja . MESON_ARGS Para argumentos que precisam de true ou false, veja . Para argumentos que precisam de yes ou no, use . Para argumentos que precisam de true ou false, veja . Para todos os outros casos, use . QMAKE_ARGS Veja . USE_* Veja . *_DEPENDS Veja . * (Qualquer variável) As variáveis ​​mais usadas possuem assistentes diretos, veja . Para qualquer variável sem um assistente específico, veja . Dependências de opções Quando uma opção precisa de outra opção para funcionar, veja . Conflitos de opções Quando uma opção não funciona se outra também estiver ativada, consulte . Targets para Build Quando uma opção precisa de algum processamento extra, veja . <varname>OPTIONS_SUB</varname> Se OPTIONS_SUB está definido com yes então cada uma das opções adicionadas a OPTIONS_DEFINE será adicionada em PLIST_SUB e SUB_LIST, por exemplo: OPTIONS_DEFINE= OPT1 OPTIONS_SUB= yes é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} PLIST_SUB+= OPT1="" NO_OPT1="@comment " SUB_LIST+= OPT1="" NO_OPT1="@comment " .else PLIST_SUB+= OPT1="@comment " NO_OPT1="" SUB_LIST+= OPT1="@comment " NO_OPT1="" .endif O valor de OPTIONS_SUB é ignorado. Definindo-o com qualquer valor irá adicionar entradas PLIST_SUB e SUB_LIST para todas as opções. <varname><replaceable>OPT</replaceable>_USE</varname> e <varname><replaceable>OPT</replaceable>_USE_OFF</varname> Quando a opção OPT é selecionada, para cada par key=value em OPT_USE, value é anexado ao USE_KEY correspondente. E se value tiver espaços, substitua-os por vírgulas e eles serão alterados de volta para espaços durante o processamento. OPT_USE_OFF funciona da mesma maneira, quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_USE= mysql=yes xorg=x11,xextproto,xext,xrandr OPT1_USE_OFF= openssl=yes é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} USE_MYSQL= yes USE_XORG= x11 xextproto xext xrandr .else USE_OPENSSL= yes .endif Assistentes <varname>CONFIGURE_ARGS</varname> <varname><replaceable>OPT</replaceable>_CONFIGURE_ENABLE</varname> Quando a opção OPT é selecionada, para cada valor em OPT_CONFIGURE_ENABLE, --enable-valor será anexado a CONFIGURE_ARGS. Quando a opção OPT não for selecionada, --disable-valor será anexado a CONFIGURE_ARGS. Um argumento opcional pode ser especificado com um símbolo =. Este argumento é apenas anexado na entrada de opção do script configure --enable-valor. Por exemplo: OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_ENABLE= test1 test2 OPT2_CONFIGURE_ENABLE= test2=exhaustive é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-test1 --enable-test2 .else CONFIGURE_ARGS+= --disable-test1 --disable-test2 .endif .if ${PORT_OPTIONS:MOPT2} CONFIGURE_ARGS+= --enable-test2=exhaustive .else CONFIGURE_ARGS+= --disable-test2 .endif <varname><replaceable>OPT</replaceable>_CONFIGURE_WITH</varname> Quando a opção OPT é selecionada, para cada valor em OPT_CONFIGURE_WITH, --with-valor será anexado a CONFIGURE_ARGS. Quando a opção OPT não for selecionada, --without-valor será anexado a CONFIGURE_ARGS. Um argumento opcional pode ser especificado com um símbolo =. Este argumento é apenas anexado na entrada de opção do script configure --with-valor. Por exemplo: OPTIONS_DEFINE= OPT1 OPT2 OPT1_CONFIGURE_WITH= test1 OPT2_CONFIGURE_WITH= test2=exhaustive é equivalente a: OPTIONS_DEFINE= OPT1 OPT2 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --with-test1 .else CONFIGURE_ARGS+= --without-test1 .endif .if ${PORT_OPTIONS:MOPT2} CONFIGURE_ARGS+= --with-test2=exhaustive .else CONFIGURE_ARGS+= --without-test2 .endif <varname><replaceable>OPT</replaceable>_CONFIGURE_ON</varname> e <varname><replaceable>OPT</replaceable>_CONFIGURE_OFF</varname> Quando a opção OPT é selecionada, o valor de OPT_CONFIGURE_ON, se definido, é anexado a CONFIGURE_ARGS. OPT_CONFIGURE_OFF funciona da mesma maneira, quando OPTnão for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_CONFIGURE_ON= --add-test OPT1_CONFIGURE_OFF= --no-test é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --add-test .else CONFIGURE_ARGS+= --no-test .endif Na maioria das vezes, os assistentes em e fornecem uma funcionalidade mais curta e abrangente. Assistentes <varname>CMAKE_ARGS</varname> <varname><replaceable>OPT</replaceable>_CMAKE_ON</varname> e <varname><replaceable>OPT</replaceable>_CMAKE_OFF</varname> Quando a opção OPT é selecionada, o valor de OPT_CMAKE_ON, se definido, é anexado a CMAKE_ARGS. OPT_CMAKE_OFF funciona da mesma maneira, mas quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_CMAKE_ON= -DTEST:BOOL=true -DDEBUG:BOOL=true OPT1_CMAKE_OFF= -DOPTIMIZE:BOOL=true é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true .else CMAKE_ARGS+= -DOPTIMIZE:BOOL=true .endif Veja para um assistente mais curto quando o valor for booleano. <varname><replaceable>OPT</replaceable>_CMAKE_BOOL</varname> e <varname><replaceable>OPT</replaceable>_CMAKE_BOOL_OFF</varname> Quando a opção OPT é selecionada, para cada valor em OPT_CMAKE_BOOL, -Dvalor:BOOL=true será anexado a CMAKE_ARGS. Quando a opção OPT não for selecionada, -Dvalor:BOOL=false será anexado a CONFIGURE_ARGS. O OPT_CMAKE_BOOL_OFF é o oposto, -Dvalor:BOOL=false será anexado a CMAKE_ARGS quando a opção é selecionada, e a entrada -Dvalor:BOOL=true quando a opção não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_CMAKE_BOOL= TEST DEBUG OPT1_CMAKE_BOOL_OFF= OPTIMIZE é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} CMAKE_ARGS+= -DTEST:BOOL=true -DDEBUG:BOOL=true \ -DOPTIMIZE:BOOL=false .else CMAKE_ARGS+= -DTEST:BOOL=false -DDEBUG:BOOL=false \ -DOPTIMIZE:BOOL=true .endif Assistentes <varname>MESON_ARGS</varname> <varname><replaceable>OPT</replaceable>_MESON_ON</varname> e <varname><replaceable>OPT</replaceable>_MESON_OFF</varname> Quando a opção OPT é selecionada, o valor de OPT_MESON_ON, se definido, é anexado a MESON_ARGS. OPT_MESON_OFF funciona da mesma maneira, quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_MESON_ON= -Dopt=1 OPT1_MESON_OFF= -Dopt=2 é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dopt=1 .else MESON_ARGS+= -Dopt=2 .endif <varname><replaceable>OPT</replaceable>_MESON_TRUE</varname> e <varname><replaceable>OPT</replaceable>_MESON_FALSE</varname> Quando a opção OPT é selecionada, para cada valor em OPT_MESON_TRUE, -Dvalor=true será anexado a MESON_ARGS. Quando a opção OPT não for selecionada, -Dvalor=false será anexado a MESON_ARGS. O OPT_MESON_FALSE é o oposto, a entrada -Dvalor=false será anexado a MESON_ARGS quando a opção for selecionada e a entrada -Dvalor=true quando a opção não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_MESON_TRUE= test debug OPT1_MESON_FALSE= optimize é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=true -Ddebug=true \ -Doptimize=false .else MESON_ARGS+= -Dtest=false -Ddebug=false \ -Doptimize=true .endif <varname><replaceable>OPT</replaceable>_MESON_YES</varname> e <varname><replaceable>OPT</replaceable>_MESON_NO</varname> Quando a opção OPT é selecionada, para cada entrada dentro da variável OPT_MESON_YES a entrada -D=yes é anexada a variável MESON_ARGS. Quando a opção OPTnão é selecionada, então a entrada -D=no é anexada a variável MESON_ARGS. O OPT_MESON_NO é o oposto, a entrada -D=no é anexada a variável MESON_ARGS quando a opção é selecionada e a entrada -D=yes quando a opção não é selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_MESON_YES= test debug OPT1_MESON_NO= optimize é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=yes -Ddebug=yes \ -Doptimize=no .else MESON_ARGS+= -Dtest=no -Ddebug=no \ -Doptimize=yes .endif <varname><replaceable>OPT</replaceable>_MESON_ENABLED</varname> e <varname><replaceable>OPT</replaceable>_MESON_DISABLED</varname> Quando a opção OPT é selecionada, para cada valor em OPT_MESON_ENABLED, -Dvalor=enabled será anexado a MESON_ARGS. Quando a opção OPT não for selecionada, -Dvalor=disabled será anexado a MESON_ARGS. O OPT_MESON_DISABLED é o oposto, a entrada -Dvalor=disabled será anexado a MESON_ARGS quando a opção for selecionada e a entrada -Dvalor=enabled quando a opção não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_MESON_ENABLED= test OPT1_MESON_DISABLED= debug é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} MESON_ARGS+= -Dtest=enabled -Ddebug=disabled .else MESON_ARGS+= -Dtest=disabled -Ddebug=enabled .endif <varname><replaceable>OPT</replaceable>_QMAKE_ON</varname> e <varname><replaceable>OPT</replaceable>_QMAKE_OFF</varname> Quando a opção OPT é selecionada, o valor de OPT_QMAKE_ON, se definido, é anexado a QMAKE_ARGS. OPT_QMAKE_OFF funciona da mesma maneira, quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_QMAKE_ON= -DTEST:BOOL=true OPT1_QMAKE_OFF= -DPRODUCTION:BOOL=true é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} QMAKE_ARGS+= -DTEST:BOOL=true .else QMAKE_ARGS+= -DPRODUCTION:BOOL=true .endif <varname><replaceable>OPT</replaceable>_IMPLIES</varname> Fornece uma maneira de adicionar dependências entre as opções. Quando OPT for selecionada, todas as opções listadas nesta variável também serão selecionadas. Usando o OPT_CONFIGURE_ENABLE descrito anteriormente para demonstrar: OPTIONS_DEFINE= OPT1 OPT2 OPT1_IMPLIES= OPT2 OPT1_CONFIGURE_ENABLE= opt1 OPT2_CONFIGURE_ENABLE= opt2 É equivalente a: OPTIONS_DEFINE= OPT1 OPT2 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt1 .else CONFIGURE_ARGS+= --disable-opt1 .endif .if ${PORT_OPTIONS:MOPT2} || ${PORT_OPTIONS:MOPT1} CONFIGURE_ARGS+= --enable-opt2 .else CONFIGURE_ARGS+= --disable-opt2 .endif Uso Simples de <varname><replaceable>OPT</replaceable>_IMPLIES</varname> Este port tem uma opção X11 e uma opção GNOME que precisa da opção X11 selecionada para poder compilar. OPTIONS_DEFINE= X11 GNOME OPTIONS_DEFAULT= X11 X11_USE= xorg=xi,xextproto GNOME_USE= gnome=gtk30 GNOME_IMPLIES= X11 <varname><replaceable>OPT</replaceable>_PREVENTS</varname> e <varname><replaceable>OPT</replaceable>_PREVENTS_MSG</varname> Fornece uma maneira de adicionar conflitos entre as opções. Quando OPT for selecionada, todas as opções listadas em OPT_PREVENTS devem estar desmarcadas. Se OPT_PREVENTS_MSG estiver definido e um conflito for acionado, seu conteúdo será exibido explicando o por que do conflito. Por exemplo: OPTIONS_DEFINE= OPT1 OPT2 OPT1_PREVENTS= OPT2 OPT1_PREVENTS_MSG= OPT1 and OPT2 enable conflicting options É aproximadamente equivalente a: OPTIONS_DEFINE= OPT1 OPT2 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT2} && ${PORT_OPTIONS:MOPT1} BROKEN= Option OPT1 conflicts with OPT2 (select only one) .endif A única diferença é que o primeiro irá apresentar um erro depois de executar make config, sugerindo alterar as opções selecionadas. Uso Simples de <varname><replaceable>OPT</replaceable>_PREVENTS</varname> Este port tem as opções X509 e SCTP. Ambas as opções adicionam patches, mas os patches entram em conflito uns com os outros, então eles não podem ser selecionados ao mesmo tempo. OPTIONS_DEFINE= X509 SCTP SCTP_PATCHFILES= ${PORTNAME}-6.8p1-sctp-2573.patch.gz:-p1 SCTP_CONFIGURE_WITH= sctp X509_PATCH_SITES= http://www.roumenpetrov.info/openssh/x509/:x509 X509_PATCHFILES= ${PORTNAME}-7.0p1+x509-8.5.diff.gz:-p1:x509 X509_PREVENTS= SCTP X509_PREVENTS_MSG= X509 and SCTP patches conflict <varname><replaceable>OPT</replaceable>_VARS</varname> e <varname><replaceable>OPT</replaceable>_VARS_OFF</varname> Fornece uma maneira genérica de definir e acrescentar valores em variáveis. Antes de usar OPT_VARS e OPT_VARS_OFF, veja se já não existe um assistente mais específico disponível em . Quando a opção OPT está selecionada e OPT_VARS definido, os pares chave=valor e chave+=valor são avaliados a partir da variável OPT_VARS. Um = sobrescreve o valor existente da CHAVE, um += acrescenta o valor a chave. OPT_VARS_OFF funciona da mesma maneira, quando a opção OPT não for selecionada. OPTIONS_DEFINE= OPT1 OPT2 OPT3 OPT1_VARS= also_build+=bin1 OPT2_VARS= also_build+=bin2 OPT3_VARS= bin3_build=yes OPT3_VARS_OFF= bin3_build=no MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" é equivalente a: OPTIONS_DEFINE= OPT1 OPT2 MAKE_ARGS= ALSO_BUILD="${ALSO_BUILD}" BIN3_BUILD="${BIN3_BUILD}" .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} ALSO_BUILD+= bin1 .endif .if ${PORT_OPTIONS:MOPT2} ALSO_BUILD+= bin2 .endif .if ${PORT_OPTIONS:MOPT2} BIN3_BUILD= yes .else BIN3_BUILD= no .endif Valores contendo espaços em branco devem ser colocados entre aspas: OPT_VARS= foo="bar baz" Isso se deve ao jeito que a variável de expansão make1 lida com espaço em branco. Quando a opção OPT_VARS=foo=bar baz é expandida, a variável acaba contendo duas strings, foo=bar e baz. Mas quem está submetendo o código provavelmente pretendia que houvesse apenas uma string, foo=bar baz. Inserir o valor entre aspas impede que o espaço em branco seja usado como um delimitador. Além disso, não adicione espaços extras após o símbolo var= e antes do valor, pois assim também seria dividido o valor em duas strings. Isso não irá funcionar: OPT_VARS= foo= bar Dependências, <varname><replaceable>OPT</replaceable>_<replaceable>DEPTYPE</replaceable></varname> e <varname><replaceable>OPT</replaceable>_<replaceable>DEPTYPE</replaceable>_OFF</varname> Para qualquer um desses tipos de dependência: PKG_DEPENDS EXTRACT_DEPENDS PATCH_DEPENDS FETCH_DEPENDS BUILD_DEPENDS LIB_DEPENDS RUN_DEPENDS Quando opção OPT é selecionada, o valor de OPT_DEPTYPE, se definido, é anexado a DEPTYPE. OPT_DEPTYPE_OFF funciona da mesma forma, quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_LIB_DEPENDS= liba.so:devel/a OPT1_LIB_DEPENDS_OFF= libb.so:devel/b é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} LIB_DEPENDS+= liba.so:devel/a .else LIB_DEPENDS+= libb.so:devel/b .endif Substituição de Variáveis ​​Genéricas, <varname><replaceable>OPT</replaceable>_<replaceable>VARIABLE</replaceable></varname> e <varname><replaceable>OPT</replaceable>_<replaceable>VARIABLE</replaceable>_OFF</varname> Para qualquer uma destas variáveis: ALL_TARGET BINARY_ALIAS BROKEN CATEGORIES CFLAGS CONFIGURE_ENV CONFLICTS CONFLICTS_BUILD CONFLICTS_INSTALL CPPFLAGS CXXFLAGS DESKTOP_ENTRIES DISTFILES EXTRACT_ONLY EXTRA_PATCHES GH_ACCOUNT GH_PROJECT GH_SUBDIR GH_TAGNAME GH_TUPLE GL_ACCOUNT GL_COMMIT GL_PROJECT GL_SITE GL_SUBDIR GL_TUPLE IGNORE INFO INSTALL_TARGET LDFLAGS LIBS MAKE_ARGS MAKE_ENV MASTER_SITES PATCHFILES PATCH_SITES PLIST_DIRS PLIST_FILES PLIST_SUB PORTDOCS PORTEXAMPLES SUB_FILES SUB_LIST TEST_TARGET USES Quando a opção OPT é selecionada, o valor da variável OPT_ABOVEVARIABLE, se definido, é anexado a ABOVEVARIABLE. OPT_ABOVEVARIABLE_OFF funciona da mesma maneira, quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 OPT1_USES= gmake OPT1_CFLAGS_OFF= -DTEST é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MOPT1} USES+= gmake .else CFLAGS+= -DTEST .endif Algumas variáveis ​​não estão nesta lista, em particular PKGNAMEPREFIX e PKGNAMESUFFIX. Isso é intencional. Um port não deve mudar seu nome quando alguma de suas opções forem alteradas. Algumas dessas variáveis, pelo menos ALL_TARGET, DISTFILES e INSTALL_TARGET, tem seus valores padrão definidos depois das opções serem processadas. Com estas linhas no Makefile: ALL_TARGET= all DOCS_ALL_TARGET= doc Se a opção DOCS estiver ativada, ALL_TARGET terá o valor all doc; se a opção estiver desativada, ela terá o valor all. Com apenas a linha do assistente de opções no Makefile: DOCS_ALL_TARGET= doc Se a opção DOCS estiver ativada, ALL_TARGET terá o valor doc; se a opção estiver desativada, ela terá o valor all. Targets Adicionais de Compilação, <buildtarget><replaceable>target</replaceable>-<replaceable>OPT</replaceable>-on</buildtarget> e <buildtarget><replaceable>target</replaceable>-<replaceable>OPT</replaceable>-off</buildtarget> Estes targets de Makefile podem aceitar targets extras de compilação: pre-fetch do-fetch post-fetch pre-extract do-extract post-extract pre-patch do-patch post-patch pre-configure do-configure post-configure pre-build do-build post-build pre-install do-install post-install post-stage pre-package do-package post-package Quando a opção OPT é selecionada, o target TARGET-OPT-on, se definido, é executado após TARGET. TARGET-OPT-off funciona da mesma maneira, quando OPT não for selecionada. Por exemplo: OPTIONS_DEFINE= OPT1 post-patch: @${REINPLACE_CMD} -e 's/echo/true/' ${WRKSRC}/Makefile post-patch-OPT1-on: @${REINPLACE_CMD} -e '/opt1/d' ${WRKSRC}/Makefile post-patch-OPT1-off: @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${LOCALBASE}/bin/|' ${WRKSRC}/Makefile é equivalente a: OPTIONS_DEFINE= OPT1 .include <bsd.port.options.mk> post-patch: @${REINPLACE_CMD} -e 's/echo/true/' ${WRKSRC}/Makefile .if ${PORT_OPTIONS:MOPT1} @${REINPLACE_CMD} -e '/opt1/d' ${WRKSRC}/Makefile .else @${REINPLACE_CMD} -e '/opt1/s|/usr/bin/|${LOCALBASE}/bin/|' ${WRKSRC}/Makefile .endif Especificando o Diretório de Trabalho Cada port é extraído em um diretório de trabalho, que deve ter permissão de escrita. O sistema de ports tem por padrão os DISTFILES descompactado em um diretório chamado ${DISTNAME}. Em outras palavras, se o Makefile tem: PORTNAME= foo DISTVERSION= 1.0 então os arquivos de distribuição do port contêm um diretório de nível superior, foo-1.0, e o resto dos arquivos estão localizados nesse diretório. Diversas variáveis ​​podem ser substituídas se não for esse o caso. <varname>WRKSRC</varname> A variável lista o nome do diretório que é criado quando os distfiles do aplicativo são extraídos. Se o exemplo anterior for extraído em um diretório chamado foo (e não foo-1.0) escreva: WRKSRC= ${WRKDIR}/foo ou possivelmente WRKSRC= ${WRKDIR}/${PORTNAME} <varname>WRKSRC_SUBDIR</varname> Se o código fonte necessário para o port estiver em um subdiretório do arquivo de distribuição extraído, defina WRKSRC_SUBDIR para esse diretório. WRKSRC_SUBDIR= src <varname>NO_WRKSUBDIR</varname> Se o port não extrair para nenhum subdiretório, então configure NO_WRKSUBDIR para indicar isso. NO_WRKSUBDIR= yes Porque WRKDIR é o único diretório que deve ter permissão de escrita durante a compilação e é usado para armazenar muitos arquivos que registram o status da compilação, a extração do port será forçada para um subdiretório. Manipulando Conflitos Existem três variáveis ​​diferentes para registrar um conflito entre pacotes e ports: CONFLICTS, CONFLICTS_INSTALL e CONFLICTS_BUILD. As variáveis ​​de conflito definem automaticamente a variável IGNORE, que é mais amplamente documentada em . Ao remover um dos vários ports conflitados, é aconselhável reter CONFLICTS nos outros ports por alguns meses para atender usuários que apenas fazem atualizações de vez em quando. CONFLICTS_INSTALL Se o pacote não puder coexistir com outros pacotes (devido a conflitos de arquivos, incompatibilidades de tempo de execução, etc.). A checagem CONFLICTS_INSTALL é feita após o estágio de compilação e antes do estágio de instalação. CONFLICTS_BUILD Se o port não puder ser compilado quando outros ports específicos já estiverem instalados. Conflitos de compilação não serão registrados no pacote final. CONFLICTS Se o port não puder ser compilado quando um certo port estiver instalado e o pacote final não puder coexistir com o outro pacote. A checagem CONFLICTS é feita antes do estágio de compilação e antes do estágio de instalação. O conteúdo mais comum de uma dessas variáveis ​​é o pacote base de outro port. O pacote base é o nome do pacote sem a versão, ele pode ser obtido executando make -V PKGBASE. Uso básico de <varname>CONFLICTS<replaceable>*</replaceable></varname> dns/bind99 não pode ser instalado se dns/bind910 está presente porque eles instalam os mesmos arquivos. Primeiro, reúna o pacote base para usar: % make -C dns/bind99 -V PKGBASE bind99 % make -C dns/bind910 -V PKGBASE bind910 Então adicione ao Makefile do dns/bind99: CONFLICTS_INSTALL= bind910 E adicione ao Makefile do dns/bind910: CONFLICTS_INSTALL= bind99 Às vezes, apenas uma versão de outro port é incompatível, neste caso, use o nome completo do pacote, com a versão, e use shell globs, como * e ? para garantir que todas as versões possíveis sejam correspondidas. Usando <varname>CONFLICTS<replaceable>*</replaceable></varname> Com Globs. Nas versões 2.0 até 2.4.1_2, deskutils/gnotime instalava uma versão integrada de databases/qof. Para refletir este passado, o Makefile do database/qof contém: CONFLICTS_INSTALL= gnotime-2.[0-3]* \ gnotime-2.4.0* gnotime-2.4.1 \ gnotime-2.4.1_[12] As primeira entrada corresponde as versões 2.0 até 2.3, a segunda corresponde todas as revisões de 2.4.0, a terceira corresponde a versão exata 2.4.1, e a última corresponde a primeira e segunda revisão da versão 2.4.1. deskutils/gnotime não possui nenhuma linha de conflitos porque sua versão atual não conflita com mais nada. Instalando Arquivos O estágio install é muito importante para o usuário final porque ele adiciona arquivos ao sistema. Todos os comandos adicionais de estágios *-install dos Makefile's de port devem ser mostrados na tela. Não silencie esses comandos com @ ou .SILENT. Macros <varname>INSTALL_<replaceable>*</replaceable></varname> Use as macros fornecidas em bsd.port.mk para garantir a propriedade correta dos arquivos nos targets *-install do port. Defina a propriedade diretamente em pkg-plist com as entradas correspondentes, como @(owner,group,), @owner owner, e @group group. Esses operadores funcionam até serem substituídos, ou até o final do pkg-plist, lembre-se de redefini-los depois que eles não forem mais necessários. O valor de propriedade padrão é root:wheel. Veja para maiores informações. INSTALL_PROGRAM é um comando para instalar executáveis ​​binários. INSTALL_SCRIPT é um comando para instalar scripts executáveis. INSTALL_LIB é um comando para instalar bibliotecas compartilhadas (mas não bibliotecas estáticas). INSTALL_KLD é um comando para instalar módulos carregáveis ​​do kernel. Algumas arquiteturas não gostam de ter os módulos otimizados (stripped), então use este comando em vez de INSTALL_PROGRAM. INSTALL_DATA é um comando para instalar dados compartilháveis, incluindo bibliotecas estáticas. INSTALL_MAN é um comando para instalar manpages e outras documentações (ele não realiza nenhuma compactação). Estas variáveis ​​parametrizam o comando install1 com as flags apropriadas para cada situação. Não use INSTALL_LIB para instalar bibliotecas estáticas, porque otimiza-las (strip) torna-as sem utilidade. Use INSTALL_DATA neste caso. Otimizando (Stripping) Binários e Bibliotecas Compartilhadas Os binários instalados devem ser otimizados (stripped). Não otimize (strip) os binários manualmente, a menos que seja absolutamente necessário. A macro INSTALL_PROGRAM instala e otimiza (strip) o binário ao mesmo tempo. A macro INSTALL_LIB faz o mesmo com as bibliotecas compartilhadas. Quando um arquivo deve ser otimizado (stripped), mas as macros INSTALL_PROGRAM e INSTALL_LIB não são desejadas, ${STRIP_CMD} otimiza (strips) o programa ou a biblioteca compartilhada. Isso geralmente é feito no target post-install. Por exemplo: post-install: ${STRIP_CMD} ${STAGEDIR}${PREFIX}/bin/xdl Quando vários arquivos precisam ser otimizados (stripped): post-install: .for l in geometry media body track world ${STRIP_CMD} ${STAGEDIR}${PREFIX}/lib/lib${PORTNAME}-${l}.so.0 .endfor Use file1 em um arquivo para determinar se ele foi otimizado (stripped). Binários são relatados por file1 como stripped ou not stripped. Além disso,strip1 irá detectar programas que já foram otimizados (stripped) e retornar o comando sem erros. Quando WITH_DEBUG estiver definido, os arquivos elf não devem ser otimizados (stripped). As variáveis ​​(STRIP_CMD, INSTALL_PROGRAM, INSTALL_LIB, ...) e USES fornecidas pelo framework lidam com isso automaticamente. Alguns softwares, adicionam -s em seus LDFLAGS, neste caso, ou remova o -s se WITH_DEBUG estiver definido, ou remova o incondicionalmente e use STRIP_CMD em post-install. Instalando uma Árvore Inteira de Arquivos Às vezes, um grande número de arquivos devem ser instalados preservando sua organização hierárquica. Por exemplo, copiando de uma árvore de diretórios inteira do WRKSRC para um diretório de destino sob PREFIX. Observe que PREFIX, EXEMPLESDIR, DATADIR e outras variáveis ​​de caminho sempre devem ser precedidas por STAGEDIR para respeitar o staging (ver ). Existem duas macros para essa situação. A vantagem de usar essas macros em vez de cp é que elas garantem a propriedade e permissão adequada dos arquivos nos arquivos de destino. A primeira macro, COPYTREE_BIN, irá definir todos os arquivos instalados como sendo executáveis, sendo assim, adequado para instalações em PREFIX/bin. A segunda macro,COPYTREE_SHARE, não define permissões de execução nos arquivos e, portanto, é adequado para instalar arquivos sob o destino PREFIX/share. post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && ${COPYTREE_SHARE} .${STAGEDIR}${EXAMPLESDIR}) Este exemplo irá instalar o conteúdo do diretório exemples do distfile do fornecedor para o local de exemplos apropriado do port. post-install: ${MKDIR} ${STAGEDIR}${DATADIR}/summer (cd ${WRKSRC}/temperatures && ${COPYTREE_SHARE} "June July August" ${STAGEDIR}${DATADIR}/summer) E este exemplo irá instalar os dados dos meses de verão no subdiretório summer de um DATADIR. Argumentos find adicionais podem ser passados ​​através do terceiro argumento para COPYTREE_*. Por exemplo, para instalar todos os arquivos do primeiro exemplo, exceto Makefiles, é possível usar esses comandos. post-install: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} (cd ${WRKSRC}/examples && \ ${COPYTREE_SHARE} .${STAGEDIR}${EXAMPLESDIR} "! -name Makefile") Essas macros não adicionam os arquivos instalados em pkg-plist. Eles devem ser adicionados manualmente. Para documentação opcional (PORTDOCS, veja ) e exemplos (PORTEXAMPLES), os prefixos %%PORTDOCS%% ou %%PORTEXAMPLES%% devem ser prefixados no pkg-plist. Instalar Documentação Adicional Se o software tiver alguma documentação diferente do manual padrão e páginas de informações úteis para o usuário, instale-os em DOCSDIR. Isso pode ser feito como no item anterior, no target post-install. Crie um novo diretório para o port. O nome do diretório é DOCSDIR. Isso geralmente é igual a PORTNAME. No entanto, se o usuário desejar que versões diferentes do port sejam instaladas ao mesmo tempo, PKGNAME pode ser usado. Já que apenas os arquivos listados no pkg-plist são instalados, é seguro sempre instalar documentações no STAGEDIR (veja ). Por isso, blocos .if são necessários apenas quando os arquivos forem grandes o suficiente para causarem sobrecarga significativa de I/O. post-install: ${MKDIR} ${STAGEDIR}${DOCSDIR} ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${STAGEDIR}${DOCSDIR} Por outro lado, se houver uma opção DOCS no port, instale a documentação em um taget post-install-DOCS-on. Esses targets são descritos em . Aqui estão algumas variáveis ​​úteis e como elas são expandidas por padrão quando usadas no Makefile: DATADIR é expandido para PREFIX/share/PORTNAME. DATADIR_REL é expandido para share/PORTNAME. DOCSDIR é expandido para PREFIX/share/doc/PORTNAME. DOCSDIR_REL é expandido para share/doc/PORTNAME. EXEMPLESDIR é expandido para PREFIX/share/examples/PORTNAME. EXAMPLESDIR_REL é expandido para share/examples/PORTNAME. A opção DOCS controla apenas a documentação adicional instalada em DOCSDIR. Não se aplica a páginas de manual e páginas de informações padrão. Arquivos instalados em EXEMPLESDIR são controlados pela opção EXEMPLES. Essas variáveis ​​são exportadas para PLIST_SUB. Quando possível, seus valores aparecerão como nomes de caminho relativos ao PREFIX. Isso é, por padrão share/doc/PORTNAME será substituído por %%DOCSDIR%% na lista de empacotamento e assim por diante. (Saiba mais sobre substituições pkg-plist aqui. Todos os arquivos e diretórios de documentação instalados condicionalmente são incluídos no pkg-plist com o prefixo %%PORTDOCS%%, por exemplo: %%PORTDOCS%%%%DOCSDIR%%/AUTHORS %%PORTDOCS%%%%DOCSDIR%%/CONTACT Como uma alternativa para listar os arquivos de documentação em pkg-plist, um port pode definir a variável PORTDOCS com uma lista de nomes de arquivo e padrões shell glob para adicionar à lista de empacotamento final. Os nomes serão relativos a DOCSDIR. Portanto, um port que utiliza PORTDOCS e usa um local não padrão para sua documentação, deve definir DOCSDIR adequadamente. Se um diretório estiver listado em PORTDOCS ou ser correspondido por um padrão glob dessa variável, toda a sub árvore de arquivos e diretórios contidos serão registrados na lista final de empacotamento. Se a opção DOCS estiver desmarcada, os arquivos e diretórios listados em PORTDOCS não serão instalados ou adicionados à lista de empacotamento do port. A instalação da documentação em PORTDOCS como mostrado acima fica a cargo do port. Um exemplo típico de utilização PORTDOCS: PORTDOCS= README.* ChangeLog docs/* O equivalente de PORTDOCS para arquivos instalados em DATADIR e EXEMPLESDIR são PORTDATA e PORTEXAMPLES, respectivamente. O conteúdo de pkg-message é exibido na instalação. Veja a seção sobre o uso do pkg-message para mais detalhes. pkg-message não precisa ser adicionado ao pkg-plist. Subdiretórios Sob <varname>PREFIX</varname> Tente deixar o port colocar os arquivos nos subdiretórios corretos de PREFIX. Alguns ports juntam tudo e colocam os arquivos em um subdiretório com o nome do port, o que é incorreto. Além disso, muitos ports colocam todos arquivos, exceto binários, arquivos header e páginas de manual, em um subdiretório de lib, o que não funciona bem com o paradigma BSD. Muitos dos arquivos devem ser movidos para um desses diretórios: etc(setup/arquivos de configuração), libexec (executáveis ​​iniciados internamente), sbin (executáveis ​​para super-usuários/gerentes), info (documentação para o navegador de informações) ou share (arquivos independentes de arquitetura). Veja hier7 para detalhes; as regras que regem /usr praticamente se aplicam a /usr/local também. A exceção são os ports que lidam com notícias USENET. Eles podem usar PREFIX/news como um destino para seus arquivos. Use <varname>BINARY_ALIAS</varname> para Renomear Comandos Em Vez de Aplicar Patch na Compilação Quando BINARY_ALIAS é definido, ele criará links simbólicos dos comandos fornecidos, em um diretório que será prefixado para o PATH. Use-o para substituir comandos codificados na fase de compilação sem ter aplicar nenhum patch nos arquivos de compilação. Usando <varname>BINARY_ALIAS</varname> para Deixar <command>gsed</command> Disponível como <command>sed</command> Alguns ports esperam que o sed se comporte como o GNU sed e utilizam recursos que o sed1 não possui. GNU sed está disponível em textproc/gsed no FreeBSD. Use BINARY_ALIAS para substituir sed com gsed durante a compilação: BUILD_DEPENDS= gsed:textproc/gsed ... BINARY_ALIAS= sed=gsed Usando <varname>BINARY_ALIAS</varname> Para Fornecer Aliases para Comandos <command>python3</command> Codificado Um port que possui uma referência codificada para python3 em seus scripts de compilação precisará ter ele disponível no PATH em tempo de compilação. Use BINARY_ALIAS para criar um alias que aponte para o binário certo do Python 3: USES= python:3.4+,build ... BINARY_ALIAS= python3=${PYTHON_CMD} Veja para mais informações sobre USES=python. Considerações Especiais Esta seção explica as coisas mais comuns a se considerar ao criar um port. Staging bsd.port.mk espera que os ports trabalhem com um stage directory. Isso significa que um port não deve instalar arquivos diretamente nos diretórios de destino regulares (isto é, sob o PREFIX, por exemplo), mas em um diretório separado a partir do qual o pacote será construído. Em muitos casos, isso não requer privilégios de root, tornando possível criar pacotes como um usuário não privilegiado. Com o staging, o port é compilado e instalado no diretório sde estágio, STAGEDIR. Um pacote é criado a partir do diretório de estágio e, em seguida, instalado no sistema. As ferramentas Automake referem-se a este conceito como DESTDIR, mas no FreeBSD, DESTDIR tem um significado diferente (veja ). Nenhum port realmente precisa de root. Ele pode ser evitado principalmente usando USES=uidfix. Se o port ainda executa comandos como chown8, chgrp1 ou força o proprietário ou grupo com install1 então use USES=fakeroot para enganar essas chamadas. Algumas modificações no Makefile do port serão necessárias. Os meta ports, ou ports que não instalam arquivos por si mesmos e apenas dependem de outros ports, devem evitar extrair desnecessariamente mtree8 para o diretório de estágio. Este é o layout básico do diretório do pacote, e estes diretórios vazios serão vistos como órfãos. Para prevenir extração do mtree8, adicione esta linha: NO_MTREE= yes Metaports devem usar USES=metaport. Ele configura padrões para ports que não baixam, criam ou instalam nada. Staging é ativado pré-fixando a variável STAGEDIR para caminhos usados ​​nos targets pre-install, do-install e post-install (veja os exemplos no livro). Normalmente, isso inclui as variáveis PREFIX, ETCDIR, DATADIR, EXEMPLESDIR, MANPREFIX, DOCSDIR, e assim por diante. Os diretórios devem ser criados como parte do target post-install. Evite usar caminhos absolutos sempre que possível. Ports que instalam módulos do kernel devem preceder a variável STAGEDIR em seus destinos, padrão /boot/modules. Lidando com Links Simbólicos Ao criar um link simbólico, há dois casos, tanto a origem quanto o destino estão dentro de ${PREFIX}. Nesse caso, use ${RLN}. No outro caso, se um ou ambos os caminhos estiverem fora de ${PREFIX} use ${LN} -s e apenas prefixe ${STAGEDIR} para o caminho de destino. Criar Links Simbólicos Relativos, Dentro de <filename>${PREFIX}</filename> ${RLN} usa o recurso simbólico relativo do install1 que libera o mantenedor do port de computar o caminho relativo. ${RLN} ${STAGEDIR}${PREFIX}/lib/libfoo.so.42 ${STAGEDIR}${PREFIX}/lib/libfoo.so Irá gerar: % ls -lF ${STAGEDIR}${PREFIX}/lib lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 libfoo.so@ -> libfoo.so.42 -rwxr-xr-x 1 nobody nobody 15 Aug 3 11:24 libfoo.so.42* Quando usado com caminhos que não estão no mesmo diretório: ${RLN} ${STAGEDIR}${PREFIX}/libexec/foo/bar ${STAGEDIR}${PREFIX}/bin/bar Irá gerar automaticamente os links simbólicos relativos: % ls -lF ${STAGEDIR}${PREFIX}/bin lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 bar@ -> ../libexec/foo/bar Criar Links Simbólicos Absolutos, Fora de <filename>${PREFIX}</filename> Ao criar um link simbólico fora de ${PREFIX}, a origem não deve conter ${STAGEDIR}, o destino no entanto, deve: ${LN} -sf /var/cache/${PORTNAME} ${STAGEDIR}${PREFIX}/share/${PORTNAME} Irá gerar: % ls -lF ${STAGEDIRDIR}${PREFIX}/share lrwxr-xr-x 1 nobody nobody 181 Aug 3 11:27 foo@ -> /var/cache/foo Bibliotecas Empacotadas (Bundled) Esta seção explica porque as dependências agrupadas(bundled) são consideradas ruins e o que fazer com elas. Por Que as Bibliotecas Agrupadas(Bundled) São Ruins Alguns softwares requerem que o mantenedor do port localize bibliotecas de terceiros e adicione as dependências necessárias ao port. Outros softwares agrupam todas as bibliotecas necessárias no arquivo de distribuição. A segunda abordagem parece mais fácil no começo, mas há algumas desvantagens sérias: Esta lista é vagamente baseada nas wikis Fedora e Gentoo, ambas licenciadas sob CC-BY-SA 3.0. Segurança Se vulnerabilidades forem encontradas na biblioteca e arrumadas no upstream, elas podem não ser consertadas na biblioteca empacotada com o port. Uma razão pode ser que o autor não esteja ciente do problema. Isto significa que o mantenedor do port deve consertá-las, ou atualizar para uma versão não vulnerável e enviar um patch para o autor. Isso tudo leva tempo, o que resulta em software vulnerável por mais tempo do que o necessário. Isso, por sua vez, torna mais difícil coordenar uma correção sem vazamento desnecessário de informações sobre a vulnerabilidade. Bugs Esse problema é semelhante ao problema de segurança no último parágrafo, mas geralmente menos grave. Forking É mais fácil para o autor criar um fork da biblioteca depois que ela é empacotada. Embora seja conveniente à primeira vista, isso significa que o código diverge do upstream, dificultando o tratamento da segurança ou outros problemas com o software. A razão para isso é que o patching se torna mais difícil. Outro problema de forking é que, como o código diverge do upstream, os bugs são resolvidos repetidamente em vez de apenas uma vez em um local central. Isso, em primeiro lugar, anula a ideia de software de código aberto. Colisão de símbolo Quando uma biblioteca é instalada no sistema, ela pode colidir com a versão empacotada. Isso pode causar erros imediatos no tempo de compilação ou link. Também pode causar erros ao executar o programa, o que pode ser mais difícil de rastrear. O último problema poderia ser causado porque as versões das duas bibliotecas são incompatíveis. Licenciamento Ao agrupar projetos de diferentes fontes, os problemas de licença podem surgir com mais facilidade, especialmente quando as licenças são incompatíveis. Desperdício de recursos Bibliotecas empacotadas desperdiçam recursos em vários níveis. Demora mais para compilar o aplicativo real, especialmente se essas bibliotecas já estiverem presentes no sistema. Em tempo de execução, elas podem ocupar memória desnecessária quando a biblioteca do sistema já está carregada por um programa e a biblioteca agrupada é carregada por outro programa. Desperdício de esforço Quando uma biblioteca precisa de patches para o FreeBSD, esses patches precisam ser duplicados novamente na biblioteca. Isso desperdiça tempo do desenvolvedor porque os patches podem não ser aplicados de forma limpa. Também pode ser difícil perceber que estes patches são necessários em primeiro lugar. O Que Fazer em Relação às Bibliotecas Agrupadas Sempre que possível, use a versão separada da biblioteca adicionando um LIB_DEPENDS para o port. Se esse port ainda não existir, considere criá-lo. Use bibliotecas agrupadas somente se o upstream tiver um bom histórico de segurança e se o uso de versões não agrupadas originarem patches excessivamente complexos Em alguns casos muito especiais, por exemplo, emuladores, como o Wine, um port tem que agrupar bibliotecas, porque elas estão em uma arquitetura diferente ou foram modificadas para se adequarem ao uso do software. Nesse caso, essas bibliotecas não devem ser expostas a outros ports para vinculação. Adicione BUNDLE_LIBS=yes no Makefile do port. Isso vai dizer ao pkg8 para não computar as bibliotecas fornecidas. Pergunte sempre à equipe de gerenciamento do ports portmgr@FreeBSD.org antes de adicionar isso a um port. Bibliotecas Compartilhadas Se o port instalar uma ou mais bibliotecas compartilhadas, defina a variável USE_LDCONFIG para o make , a qual irá instruir o bsd.port.mk para executar o ${LDCONFIG} -m no diretório onde a nova biblioteca está instalada (geralmente em PREFIX/lib) durante o target post-install para registrá-la no cache da biblioteca compartilhada. Esta variável, quando definida, também facilitará a adição do par @exec /sbin/ldconfig -m e @unexec /sbin/ldconfig -R no pkg-plist, para que o usuário que instalou o pacote possa começar a usar a biblioteca compartilhada imediatamente e para que a desinstalação não faça com que o sistema acredite que a biblioteca ainda está lá. USE_LDCONFIG= yes O diretório padrão pode ser substituído configurando a variável USE_LDCONFIG para uma lista de diretórios nos quais as bibliotecas compartilhadas devem ser instaladas. Por exemplo, se o port instalar bibliotecas compartilhadas em PREFIX/lib/foo e PREFIXO/lib/bar utilize isso no Makefile: USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar Por favor, verifique novamente, muitas vezes isso não é necessário ou é algo que pode ser evitado através do uso da opção -rpath ou da configuração da variável LD_RUN_PATH durante a fase de vinculação (consulte lang/mosml para um exemplo), ou através de um shell-wrapper que defina o LD_LIBRARY_PATH antes de executar o binário, como por exemplo o www/seamonkey faz. Ao instalar bibliotecas de 32 bits em um sistema de 64 bits, use USE_LDCONFIG32 como alternativa. Se o software usa o autotools, e especificamente, o libtool, adicione USES=libtool Quando o número da versão da biblioteca principal aumenta na atualização para a nova versão do port, todos os outros ports que se vinculam à biblioteca afetada devem ter seu PORTREVISION incrementado, para forçar a recompilação com a nova versão da biblioteca. Ports com Restrições de Distribuição ou Preocupações Legais As licenças variam e algumas delas impõem restrições sobre como o aplicativo pode ser empacotado, se pode ser vendido com fins lucrativos e assim por diante. É de responsabilidade de um mantenedor de um port ler os termos de licenciamento do software e certificar-se de que o projeto do FreeBSD não será responsabilizado por violá-los, redistribuindo o código fonte ou os binários compilados via FTP/HTTP ou CD-ROM. Se estiver em dúvida, entre em contato com a Lista de discussão de ports do FreeBSD Em situações como esta, as variáveis ​​descritas nas próximas seções podem ser definidas. <varname>NO_PACKAGE</varname> Esta variável indica que não podemos gerar um pacote binário da aplicação. Por exemplo, a licença pode proibir a redistribuição binária, ou pode proibir a distribuição de pacotes criados a partir de código adaptado. No entanto, o DISTFILES do port pode ser livremente espelhado no FTP/HTTP. Eles também podem ser distribuídos em um CD-ROM (ou mídia similar), a menos que a variável NO_CDROM esteja definida também. Se o pacote binário geralmente não é útil, e o aplicativo sempre deve ser compilado a partir do código-fonte, use o NO_PACKAGE. Por exemplo, se o aplicativo tiver informações de configuração específicas do site codificadas nele em tempo de compilação, defina o NO_PACKAGE Defina a variável NO_PACKAGE para uma string descrevendo o motivo pelo qual o pacote não pode ser gerado. <varname>NO_CDROM</varname> Esta variável sozinha indica que, embora tenhamos permissão para gerar pacotes binários, não podemos colocar nem esses pacotes nem o DISTFILES em um CD-ROM (ou mídia similar) para revenda. No entanto, os pacotes binários e os DISTFILES do ports ainda estarão disponíveis via FTP/HTTP. Se esta variável for definida junto com NO_PACKAGE, então apenas o DISTFILES do port estará disponível e somente via FTP/HTTP. Defina a variável NO_CDROM para uma string descrevendo o motivo pelo qual o port não pode ser redistribuído em CD-ROM. Por exemplo, use isto se a licença do port for somente para uso não comercial. <varname>NOFETCHFILES</varname> Arquivos definidos em NOFETCHFILES não podem ser obtidos de nenhum dos MASTER_SITES. Um exemplo de tal tipo de arquivo é quando o arquivo é fornecido apenas em CD-ROM pelo fornecedor. Ferramentas que verificam a disponibilidade desses arquivos nos MASTER_SITES devem ignorar estes arquivos e não informar nada sobre eles. <varname>RESTRICTED</varname> Defina esta variável sozinha, se a licença do aplicativo não permitir o espelhamento do DISTFILES e nem a distribuição do pacote binário de forma alguma. Não defina as variáveis NO_CDROM ou NO_PACKAGE juntamente com a variável RESTRICT, uma vez que esta última variável implica as anteriores. Defina a variável RESTRICTED para uma string que descreva o motivo pelo qual o port não pode ser redistribuído. Normalmente, isso indica que o port contém software proprietário e que o usuário precisará baixar manualmente o DISTFILES, possivelmente após se registrar para ter acesso ao software ou após concordar em aceitar os termos de um EULA. <varname>RESTRICTED_FILES</varname> Quando a variável RESTRICT ou a NO_CDROM está definida, o valor padrão normalmente contém ${DISTFILES}${PATCHFILES} caso contrário, ela fica vazia. Se apenas alguns dos arquivos da distribuição forem restritos, defina essa variável para listá-los. <varname>LEGAL_TEXT</varname> Se o port tem preocupações legais as quais não foram abordadas pelas variáveis ​​acima, defina a variável LEGAL_TEXT para uma string explicando a preocupação. Por exemplo, se o FreeBSD obteve uma permissão especial para redistribuir o binário, esta variável deve indicar isso. <filename>/usr/ports/LEGAL</filename> e <varname>LEGAL</varname> Um port que defina qualquer uma das variáveis ​​acima também deverá ser adicionado ao /usr/ports/LEGAL. A primeira coluna é uma glob que corresponde aos distfiles restritos. A segunda coluna é a origem do port. A terceira coluna é a saída do comando make -VLEGAL. Exemplos A maneira preferida de declarar "os distfiles para este port devem ser obtidos manualmente" é a seguinte: .if !exists(${DISTDIR}/${DISTNAME}${EXTRACT_SUFX}) IGNORE= may not be redistributed because of licensing reasons. Please visit some-website to accept their license and download ${DISTFILES} into ${DISTDIR} .endif Isso tanto informa o usuário, quanto define os metadados apropriados na máquina do usuário para uso por programas automatizados. Note que esta estrofe deve ser precedida por uma inclusão de bsd.port.pre.mk. Mecanismos de Compilação Compilando Ports em Paralelo O framework de ports do FreeBSD suporta compilação paralela usando múltiplos subprocessos do comando make, o que permite que os sistemas SMP utilizem todo o poder disponível da CPU, permitindo que as compilações dos ports sejam mais rápidas e eficazes. Isso é alcançado passando-se a flag -jX para o make1 executando no código do fornecedor. Este é o comportamento de compilação padrão dos ports. Infelizmente, nem todos os ports lidam bem com compilações paralelas e pode ser necessário desabilitar explicitamente esse recurso adicionando a variável MAKE_JOBS_UNSAFE=yes. Ela é usada quando um port é conhecido por não funcionar com a opção -jX devido a race conditions e problemas de compilação intermitentes. Ao definir a variável MAKE_JOBS_UNSAFE, é muito importante explicar com um comentário no Makefile, ou pelo menos na mensagem de commit, porque o port não pode ser compilado quando ela está ativa. Caso contrário, é quase impossível corrigir o problema ou testar se ele foi corrigido ao efetuar o commit de uma atualização em uma data posterior. <command>make</command>, <command>gmake</command>, e <command>imake</command> Existem várias implementações diferentes do make. O software portado geralmente requer uma implementação específica, como o GNU make, conhecido no FreeBSD como gmake. Se o port usa o GNU make, adicione o gmake no USES. A variável MAKE_CMD pode ser usada para referenciar o comando específico configurado pelo USES no Makefile do port. Use o MAKE_CMD apenas dentro dos Makefiles do aplicativo no WRKSRC para chamar o comando make para a implementação esperada pelo software portado. Se o port é um aplicativo X que usa o Imake para criar o Makefile do Imakefile, defina USES=imake. Veja a seção sobre USES=imake no para mais detalhes. Se o Makefile do port tem algo diferente de all como o target de compilação principal, defina a variável ALL_TARGET adequadamente. O mesmo vale para install e INSTALL_TARGET. Script <command>configure</command> Se o port usa o script configure para gerar Makefiles a partir do Makefile.in defina GNU_CONFIGURE=yes. Para dar argumentos extras ao script configure (o argumento padrão é --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir = ${MANPREFIX}/man --build = ${CONFIGURE_TARGET}), defina estes argumentos extras em CONFIGURE_ARGS. Variáveis ​​de ambiente extras podem ser passadas usando CONFIGURE_ENV. Variáveis ​​para ports que usam o <command>configure</command> Variável Significa GNU_CONFIGURE O port usa o script configure para preparar a construção. HAS_CONFIGURE Igual a GNU_CONFIGURE, exceto que o destino de configuração padrão não é adicionado a CONFIGURE_ARGS. CONFIGURE_ARGS Argumentos adicionais passados ​​para o script configure. CONFIGURE_ENV Variáveis ​​de ambiente adicionais a serem definidas para execução de script configure. CONFIGURE_TARGET Substitui o target de configuração padrão. O valor padrão é ${MACHINE_ARCH}-portbld-freebsd${OSREL}.
Usando o <command>cmake</command> Para ports que usam CMake, defina USES=cmake Variáveis ​​para ports que usam o <command>cmake</command> Variável Significa CMAKE_ARGS Flags do CMake especificas para o port a serem passadas para o binário do cmake. CMAKE_ON Para cada entrada em CMAKE_ON, um valor booleano ativado é adicionado ao CMAKE_ARGS. Veja . CMAKE_OFF Para cada entrada em CMAKE_OFF, um valor booleano desativado é adicionado ao CMAKE_ARGS. Veja . CMAKE_BUILD_TYPE Tipo de compilação (perfis de compilação predefinidos para o CMake). O padrão é Release ou Debug se a variável WITH_DEBUG estiver definida. CMAKE_SOURCE_PATH Caminho para o diretório do fonte. O padrão é ${WRKSRC}. CONFIGURE_ENV Variáveis ​​de ambiente adicionais a serem definidas para o binário do cmake.
Variáveis ​​que os usuários podem definir para compilações com <command>cmake</command> Variável Significa - CMAKE_VERBOSE - Ativa o output detalhado da compilação. Não é definido por padrão, a menos que BATCH ou PACKAGE_BUILDING esteja definido. - - - CMAKE_NOCOLOR Desativa o output colorido na compilação. Não é definido por padrão, a menos que BATCH ou PACKAGE_BUILDING esteja definido.
CMake suporta estes perfis de construção: Debug, Release, RelWithDebInfo e MinSizeRel. Debug e Release sistema de respeito de perfis *FLAGS, RelWithDebInfo e MinSizeRel ajustará CFLAGS para -O2 -g e -Os -DNDEBUG correspondentemente. O valor do invólucro inferior CMAKE_BUILD_TYPE é exportado para PLIST_SUB e deve ser usado se o port for instalar *.cmake dependendo do tipo de compilação (consulte deskutils/strigiPor exemplo). Por favor, note que alguns projetos podem definir seus próprios perfis de compilação e/ou forçar um tipo específico de compilação CMAKE_BUILD_TYPE dentro de CMakeLists.txt. Para fazer um port para tal projeto respeite CFLAGS e WITH_DEBUG, as definições CMAKE_BUILD_TYPE devem ser removidas desses arquivos. A maioria dos projetos baseados em CMake suportam um método de compilação out-of-source. A compilação out-of-source de um port é a configuração padrão. Uma compilação in-source pode ser executada usando-se o sufixo :insource. Em uma compilação out-of-source, CONFIGURE_WRKSRC, BUILD_WRKSRC e INSTALL_WRKSRC serão definidos como ${WRKDIR}/.Build e esse diretório será usado para manter todos os arquivos gerados durante os estágios de configuração e compilação, deixando o diretório de origem intacto. Exemplo de <literal>USES=cmake</literal> Este trecho demonstra o uso do CMake para um port. O CMAKE_SOURCE_PATH geralmente não é necessário, mas pode ser definido quando os fontes não estão localizados no diretório superior ou se apenas um subconjunto do projeto for compilado pelo port. USES= cmake CMAKE_SOURCE_PATH= ${WRKSRC}/subproject <varname>CMAKE_ON</varname> and <varname>CMAKE_OFF</varname> Ao adicionar valores booleanos a variável CMAKE_ARGS, será mais fácil usar as variáveis CMAKE_ON e CMAKE_OFF ​​em vez disso. Desta forma: CMAKE_ON= VAR1 VAR2 CMAKE_OFF= VAR3 É equivalente a: CMAKE_ARGS= -DVAR1:BOOL=TRUE -DVAR2:BOOL=TRUE -DVAR3:BOOL=FALSE Isto é apenas para os valores padrão desativados do CMAKE_ARGS. Os helpers descritos em usam a mesma semântica, mas para valores opcionais. Usando <command>scons</command> Se o port usa SCons, definir USES=scons Para fazer os SConstruct de terceiros respeitarem tudo o que é passado para SCons no ambiente (isto é, o mais importante, CC/CXX/CFLAGS/CXXFLAGS), altere o SConstruct para que o Evironment de compilação fique da seguinte forma: env = Environment(**ARGUMENTS) Ele poderá então ser modificado com env.Append e env.Replace Usando <command>cargo</command> Para ports que usam Cargo, defina USES=cargo Variáveis ​​que os Usuários Podem Configurar para Compilar <command>cargo</command> Variável Padrão Descrição CARGO_CRATES Lista de crates que o port depende. Cada entrada precisa ter um formato como cratename-semver por exemplo, libc-0.2.40. Os mantenedores de ports podem gerar essa lista a partir do Cargo.lock usando o comando make cargo-crates. É possível alterar manualmente as versões dos crates, mas tenha em mente as dependências transitivas. CARGO_FEATURES Lista de recursos da aplicação para compilar (lista separada por espaço). CARGO_CARGOTOML ${WRKSRC}/Cargo.toml O caminho para o Cargo.toml que será usado. CARGO_CARGOLOCK ${WRKSRC}/Cargo.lock O caminho para o Cargo.lock que será utilizado para o make cargo-crates. É possível especificar mais de um arquivo de bloqueio quando necessário. CARGO_ENV Uma lista de variáveis ​​de ambiente para passar para o Cargo semelhante a MAKE_ENV. RUSTFLAGS Flags para passar para o compilador Rust. CARGO_CONFIGURE yes Use o padrão do-configure. CARGO_UPDATE_ARGS Argumentos extras para passar para o Cargo durante a fase de configuração. Os argumentos válidos podem ser consultados com cargo update --help. CARGO_BUILDDEP yes Adiciona uma dependência de compilação em lang/rust. CARGO_CARGO_BIN ${LOCALBASE}/bin/cargo Localização do binário do cargo. CARGO_BUILD yes Use o padrão do-build. CARGO_BUILD_ARGS Argumentos extras para passar para o Cargo durante a fase de compilação. Argumentos válidos podem ser consultados com cargo buil --help. CARGO_INSTALL yes Use o padrão do-install. CARGO_INSTALL_ARGS Argumentos extras para passar para o Cargo durante a fase de instalação. Os argumentos válidos podem ser consultados com cargo isntall --help. + CARGO_INSTALL_PATH + . + Caminho para o crate instalar. Isto é passado para o cargo install via argumento --path. Quando múltiplos caminhos são informados, o cargo install é executado múltiplas vezes. + + + CARGO_TEST yes Use o padrão do-test. CARGO_TEST_ARGS Argumentos extras para passar para o Cargo durante a fase de teste. Os argumentos válidos podem ser consultados com cargo test --help. CARGO_TARGET_DIR ${WRKDIR}/target Localização do diretório de saída do cargo. CARGO_DIST_SUBDIR rust/crates Diretório relativo a DISTDIR onde os arquivos de distribuição do crate serão armazenados. CARGO_VENDOR_DIR ${WRKSRC}/cargo-crates Localização do diretório do fornecedor onde todas os crates serão extraídos. Tente manter isto sob PATCH_WRKSRC, para que os patches possam ser aplicados facilmente. CARGO_USE_GITHUB no - Ativa a busca de crates bloqueadas para commits específicos do Git no GitHub via GH_TUPLE. Isso tentará corrigir tanto o Cargo.lock quanto o Cargo.toml para apontar para os fontes off-line, em vez de buscá-los em um repositório Git durante a compilação. Use com cuidado, pois as dependências transitivas do Git não são resolvidas e corrigidas corretamente. + Ativa a busca de crates bloqueadas para commits específicos do Git no GitHub via GH_TUPLE. Isso tentará modificar o Cargo.toml no WRKDIR para apontar para os fontes offline, em vez de buscá-los em um repositório Git durante a compilação. - CARGO_GH_CARGOTOML - ${CARGO_CARGOTOML} - Lista do Cargo.toml que será corrigido quando ao utilizar o CARGO_USE_GITHUB. + CARGO_USE_GITLAB + no + O mesmo que CARGO_USE_GITHUB mas para instâncias GitLab e GL_TUPLE.
Criando um Port para uma Aplicação Simples em Rust Criar um port baseado em cargo é um processo de três estágios. Primeiro, precisamos fornecer um modelo de port que busque o arquivo de distribuição do aplicativo: PORTNAME= tokei DISTVERSIONPREFIX= v DISTVERSION= 7.0.2 CATEGORIES= devel MAINTAINER= tobik@FreeBSD.org COMMENT= Display statistics about your code USES= cargo USE_GITHUB= yes GH_ACCOUNT= Aaronepower .include <bsd.port.mk> Gerar uma distinfo inicial: % make makesum => Aaronepower-tokei-v7.0.2_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz fetch: https://codeload.github.com/Aaronepower/tokei/tar.gz/v7.0.2?dummy=/Aaronepower-tokei-v7.0.2_GH0.tar.gz: size of remote file is not known Aaronepower-tokei-v7.0.2_GH0.tar.gz 45 kB 239 kBps 00m00s Agora o arquivo de distribuição está pronto para uso e podemos ir em frente e extrair as dependências crate do pacote Cargo.lock: % make cargo-crates CARGO_CRATES= aho-corasick-0.6.4 \ ansi_term-0.11.0 \ arrayvec-0.4.7 \ atty-0.2.9 \ bitflags-1.0.1 \ byteorder-1.2.2 \ [...] A saída deste comando precisa ser colada diretamente no Makefile: PORTNAME= tokei DISTVERSIONPREFIX= v DISTVERSION= 7.0.2 CATEGORIES= devel MAINTAINER= tobik@FreeBSD.org COMMENT= Display statistics about your code USES= cargo USE_GITHUB= yes GH_ACCOUNT= Aaronepower CARGO_CRATES= aho-corasick-0.6.4 \ ansi_term-0.11.0 \ arrayvec-0.4.7 \ atty-0.2.9 \ bitflags-1.0.1 \ byteorder-1.2.2 \ [...] .include <bsd.port.mk> O distinfo precisa ser regenerado para conter todos os arquivos de distribuição dos crates: % make makesum => rust/crates/aho-corasick-0.6.4.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://crates.io/api/v1/crates/aho-corasick/0.6.4/download?dummy=/rust/crates/aho-corasick-0.6.4.tar.gz rust/crates/aho-corasick-0.6.4.tar.gz 100% of 24 kB 6139 kBps 00m00s => rust/crates/ansi_term-0.11.0.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://crates.io/api/v1/crates/ansi_term/0.11.0/download?dummy=/rust/crates/ansi_term-0.11.0.tar.gz rust/crates/ansi_term-0.11.0.tar.gz 100% of 16 kB 21 MBps 00m00s => rust/crates/arrayvec-0.4.7.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://crates.io/api/v1/crates/arrayvec/0.4.7/download?dummy=/rust/crates/arrayvec-0.4.7.tar.gz rust/crates/arrayvec-0.4.7.tar.gz 100% of 22 kB 3237 kBps 00m00s => rust/crates/atty-0.2.9.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch https://crates.io/api/v1/crates/atty/0.2.9/download?dummy=/rust/crates/atty-0.2.9.tar.gz rust/crates/atty-0.2.9.tar.gz 100% of 5898 B 81 MBps 00m00s => rust/crates/bitflags-1.0.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/. [...] Atualmente, o diretório de trabalho contém apenas os fontes dos aplicativos que nós extraímos como parte do passo make cargo-crates. Antes de tentar compilar o port, o diretório de trabalho deve ser limpo, para que os fontes do crate possam ser extraídos para o CARGO_VENDOR_DIR: % make clean ===> Cleaning for tokei-7.0.2 O port está agora pronto para uma compilação de teste e ajustes adicionais, como criar um plist, escrever uma descrição, adicionar informações de licença, opções, etc. como é normal. Ativando Recursos Adicionais do Aplicativo Alguns aplicativos definem recursos adicionais em seus Cargo.toml. Eles podem ser compilados definindo a variável CARGO_FEATURES no port. Aqui nós habilitamos as features Tokei's json e yaml: CARGO_FEATURES= json yaml Listando Licenças Crate Os crates têm suas próprias licenças. É importante saber o que elas são ao adicionar o bloco LICENSE para o port (ver). O target auxiliar cargo-crates-licenses tentará listar todas as licenças de todos os crates definidos no CARGO_CRATES. % make cargo-crates-licenses aho-corasick-0.6.4 Unlicense/MIT ansi_term-0.11.0 MIT arrayvec-0.4.7 MIT/Apache-2.0 atty-0.2.9 MIT bitflags-1.0.1 MIT/Apache-2.0 byteorder-1.2.2 Unlicense/MIT [...] Os nomes das licenças geradas com make cargo-create-licenses são expressões de licenças do SPDX 2.1 que não correspondem aos nomes de licença definidos na estrutura de ports. Eles precisam ser traduzidos para os nomes de . Usando <command>meson</command> Para ports que usam Meson, defina USES=meson Variáveis ​​para ports que usam o <command>meson</command> Variável Descrição MESON_ARGS Flags do Meson especificas para o port a serem passadas para o binário do meson. MESON_BUILD_DIR Caminho para o diretório de compilação relativo ao WRKSRC. O padrão é _build.
Exemplo de <literal>USES=meson</literal> Este trecho demonstra o uso do Meson para um port. USES= meson MESON_ARGS= -Dfoo=enabled Usando o GNU Autotools Se um port precisar de algum software GNU Autotools, adicione USES=autoreconf. Veja Para maiores informações. Usando o GNU <literal>gettext</literal> Uso Básico Se o port requer o gettext, defina USES=gettext, e o port herdará a dependência libintl.so do devel/gettext. Outros valores para uso do gettext estão listados em USES=gettext. Um caso bastante comum é um port que utilize o gettext e o configure. Geralmente, o GNU configure deve ser capaz de localizar o gettext automaticamente. USES= gettext GNU_CONFIGURE= yes Se falhar, dicas da localização do gettext podem ser informados por meio do CPPFLAGS e LDFLAGS do seguinte modo: USES= gettext CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib GNU_CONFIGURE= yes Uso Opcional Alguns softwares permitem desabilitar o NLS. Por exemplo, passando para o configure. Nesse caso, o port deve usar gettext condicionalmente, dependendo do status da opção NLS. Para ports de baixa a média complexidade, use este idioma: GNU_CONFIGURE= yes OPTIONS_DEFINE= NLS OPTIONS_SUB= yes NLS_USES= gettext NLS_CONFIGURE_ENABLE= nls .include <bsd.port.mk> Ou usando a maneira antiga de usar opções: GNU_CONFIGURE= yes OPTIONS_DEFINE= NLS .include <bsd.port.options.mk> .if ${PORT_OPTIONS:MNLS} USES+= gettext PLIST_SUB+= NLS="" .else CONFIGURE_ARGS+= --disable-nls PLIST_SUB+= NLS="@comment " .endif .include <bsd.port.mk> O próximo item na lista de tarefas a fazer é organizar de forma condicional os arquivos do catálogo de mensagens na lista de pacotes. A parte do Makefile desta tarefa já é fornecida pela expressão idiomática. Isto é explicado na seção sobre práticas avançadas de pkg-plist. Em poucas palavras, cada ocorrência de %%NLS%% dentro de pkg-plist será substituído por @Comment se o NLS estiver desativado ou por uma cadeia nula se o NLS estiver ativado. Consequentemente, as linhas prefixadas por %%NLS%% se tornarão meros comentários na lista de empacotamento final se o NLS estiver desativado; caso contrário, o prefixo será deixado de fora. Em seguida, insira %%NLS%% antes de cada caminho para um arquivo de catálogo de mensagens em pkg-plist. Por exemplo: %%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo Em casos de alta complexidade, técnicas mais avançadas podem ser necessárias, como geração dinâmica de lista de empacotamento Manipulando Diretórios do Catálogo de Mensagens Há um ponto a ser observado sobre a instalação de arquivos de catálogo de mensagens. Os diretórios de destino para eles, que residem em LOCALBASE/share/locale, não devem ser criados e removidos por um port. Os idiomas mais populares têm seus respectivos diretórios listados em PORTSDIR/Templates/BSD.local.dist. Os diretórios para muitos outros idiomas são governados pelo port devel/gettext. Consulte o seu pkg-plist e veja se o port vai instalar um arquivo de catálogo de mensagens para um idioma exclusivo. Usando <application>Perl</application> E se o MASTER_SITES estiver configurado para CPAN, o subdiretório correto é geralmente selecionado automaticamente. Se o subdiretório padrão estiver errado, o CPAN/Module pode ser usado para alterá-lo. O MASTER_SITES também pode ser definido para o antigo MASTER_SITE_PERL_CPAN, então o valor preferido para o MASTER_SITE_SUBDIR é o nome da hierarquia de nível superior. Por exemplo, o valor recomendado para p5-Module-Name é Module. A hierarquia de nível superior pode ser examinada em cpan.org. Isso mantém o port funcionando quando o autor do módulo muda. A exceção a essa regra é quando o diretório relevante não existe ou o distfile não existe neste diretório. Neste caso, é permitido usar o id do autor como MASTER_SITE_SUBDIR. A macro CPAN: AUTOR pode ser usada, a qual será traduzida para o diretório de autor com hash. Por exemplo,CPAN: AUTOR será convertido para autores/id/A/AU/AUTOR. Quando um port precisa de suporte a Perl, ele deve definir USES=perl5 com o opcional USE_PERL5 descrito em descrição do USES no perl5. Variáveis ​​Somente Leitura para Ports Que Usam <application>Perl</application> Variáveis ​​Somente de Leitura Significa PERL O caminho completo do interpretador Perl 5, seja no sistema ou instalado a partir de um port, mas sem o número da versão. Use isso quando o software precisar do caminho para o interpretador Perl. Para substituir as linhas #! em scripts, use USES=shebangfix. PERL_VERSION A versão completa do Perl instalada (por exemplo, 5,8,9). PERL_LEVEL A versão do Perl instalada como um inteiro no formato MNNNPP (por exemplo,500809). PERL_ARCH Local no qual o Perl armazena as bibliotecas dependentes da arquitetura. O valor padrão aponta para ${ARCH}-freebsd. PERL_PORT Nome do port Perl instalado (por exemplo,perl5). SITE_PERL Nome do diretório para onde vão os pacotes Perl específicos do site. Esse valor é adicionado a PLIST_SUB.
Ports de Módulos Perl que não possuem um site oficial devem linkar para cpan.org na linha WWW do pkg-descr. O formato preferido para a URL é http://search.cpan.org/dist/Module-Name/ (incluindo a barra final). Não use ${SITE_PERL} em declarações de dependência. Fazê-lo pressupõe que o perl5.mk foi incluído, o que nem sempre é verdade. Os ports que dependem desse port terão dependências incorretas se os arquivos desse port forem movidos posteriormente em uma atualização. O caminho certo para declarar as dependências do módulo Perl é mostrado no exemplo abaixo. Exemplo de Dependência Perl p5-IO-Tee>=0.64:devel/p5-IO-Tee Para ports Perl que instalam páginas de manual, as macros PERL5_MAN3 e PERL5_MAN1 podem ser usadas dentro do pkg-plist. Por exemplo, lib/perl5/5.14/man/man1/event.1.gz lib/perl5/5.14/man/man3/AnyEvent::I3.3.gz pode ​​ser substituído por %%PERL5_MAN1%%/event.1.gz %%PERL5_MAN3%%/AnyEvent::I3.3.gz Não existem macros PERL5_MANx para as outras seções (sendo x igual a 2 e de 4 até 9) porque estes são instalados nos diretórios comuns. Um Port Que Requer Perl Apenas para Compilar Como o valor padrão para USE_PERL5 é build e run, configure-o para: USES= perl5 USE_PERL5= build Um Port Que Também Requer Perl Para Patch De tempos em tempos, o uso do sed1 para patches se torna insuficiente. Quando usar perl1 fica mais facil, para isso utilize: USES= perl5 USE_PERL5= patch build run Um Módulo Perl Que Precisa de <literal>ExtUtils::MakeMaker</literal> para Compilar A maioria dos módulos Perl vêm com um script configure Makefile.PL. Neste caso, defina: USES= perl5 USE_PERL5= configure Um Módulo Perl Que Precisa <literal>Módulo::Build</literal> para Compilar Quando um modulo Perl vem com um script configure Build.PL, pode exigir Module:Build, nesse caso, defina USES= perl5 USE_PERL5= modbuild Se for ao contrário, e exigir Module::Build::Tiny, defina USES= perl5 USE_PERL5= modbuildtiny Usando o X11 Componentes X.Org - A implementação do X11 disponível na Coleção de Ports é o X.Org. Se o aplicativo depender de componentes X, defina USE_XORG a lista de componentes necessários. Componentes disponíveis, no momento da escrita, são: + A implementação do X11 disponível na Coleção de Ports é o X.Org. Se o aplicativo depender de componentes X, defina USE_XORG na lista de componentes necessários. Uma lista completa pode ser encontrada em . Uma lista sempre atualizada pode ser encontrada em /usr/ports/Mk/bsd.xorg.mk. - bigreqsproto compositeproto damageproto dmx dmxproto dri2proto dri3proto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx pciaccess pixman presentproto printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xbitmaps xcb xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-macros xorg-server xp xpm xprintapputil xprintutil xproto xproxymngproto xrandr xrender xres xscrnsaver xshmfence xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm. + + Componentes Disponíveis do X.Org - A lista sempre atualizada pode ser encontrada em /usr/ports/Mk/bsd.xorg.mk + + + + Nome + Descrição + + + + + + dmx + Biblioteca de extensão DMX + + + + fontenc + Biblioteca fontenc + + + + fontutil + Crie um índice de arquivos de fontes X em um diretório + + + + ice + Biblioteca Inter Client Exchange para X11 + + + + libfs + Biblioteca FS + + + + oldx + Antiga Biblioteca X + + + + pciaccess + Biblioteca Genérica de acesso ao PCI + + + + pixman + Biblioteca de manipulação de pixels de baixo nível + + + + sm + Biblioteca de Gerenciamento de Sessão para X11 + + + + x11 + Biblioteca X11 + + + + xau + Biblioteca do Protocolo de Autenticação para o X11 + + + + xaw + Biblioteca de Widgets do X Athena + + + + xaw6 + Biblioteca de Widgets do X Athena + + + + xaw7 + Biblioteca de Widgets do X Athena + + + + xbitmaps + Arquivos bitmaps do X.Org + + + + xcb + Biblioteca do protocolo X C-language Binding (XCB) + + + + xcomposite + Biblioteca de extensão X Composite + + + + xcursor + Biblioteca de carregamento do cursor X no lado do cliente + + + + xdamage + Biblioteca de extensão X Damage + + + + xdmcp + Biblioteca do Protocolo de Controle do X Display Manager + + + + xevie + Biblioteca Xevie + + + + xext + Biblioteca de Extensão X11 + + + + xfixes + Biblioteca de extensão X Fixes + + + + xfont + Biblioteca de fontes do X + + + + xfont2 + Biblioteca de fontes do X versão 2.x + + + + xfontcache + Biblioteca Xfontcache + + + + xft + API de fontes do lado do cliente para aplicativos X + + + + xi + Biblioteca de extensão X Input + + + + xinerama + Biblioteca X11 Xinerama + + + + xkbfile + Biblioteca XKB + + + + xkbui + Biblioteca xkbui + + + + xmu + Biblioteca de Utilitários Diversos do X + + + + xmuu + Biblioteca de Utilitários Diversos do X + + + + xorg-macros + Macros aclocal de desenvolvimento X.Org + + + + xorg-server + Servidor X do X.Org e programas relacionados + + + + xorgproto + Cabeçalhos de protocolo do X.Org + + + + xp + Biblioteca de impressão do X + + + + xpm + Biblioteca Pixmap do X + + + + xprintapputil + Biblioteca XprintAppUtil + + + + xprintutil + Biblioteca XprintUtil + + + + xrandr + Biblioteca de extensão X Resize e Rotate + + + + xrender + Biblioteca de extensão X Render + + + + xres + Biblioteca de uso X Resource + + + + xscrnsaver + Biblioteca XScrnSaver + + + + xshmfence + Memória compartilhada 'SyncFence' primitiva de sincronização + + + + xt + Biblioteca X Toolkit + + + + xtrans + Código de rede abstrato para X + + + + xtrap + Biblioteca XTrap + + + + xtst + Extensão X Test + + + + xv + Biblioteca de Extensão X Video + + + + xvmc + Biblioteca X Video Extension Motion Compensation + + + + xxf86dga + X DGA Extension + + + + xxf86misc + Extensão X XF86-Misc + + + + xxf86vm + Extensão X Vidmode + + + +
+ O Projeto Mesa é um esforço para fornecer implementação gratuita do OpenGL. Para especificar uma dependência em vários componentes deste projeto, use a variável USE_GL. Veja para a lista completa dos componentes disponíveis. Para compatibilidade com versões anteriores, o valor yes direciona para glu. Exemplo <varname>USE_XORG</varname> USES= gl USE_GL= glu USE_XORG= xrender xft xkbfile xt xaw Variáveis ​​para Ports Que Usam X USES= imake O port usa imake XMKMF Definir o caminho de xmkmf se não no PATH. Padrão para xmkmf -a.
Usando Variáveis ​​Relacionadas ao X11 # Use some X11 libraries USE_XORG= x11 xpm Ports que Requerem Motif Se o port requer uma biblioteca Motif, defina USES=motif no Makefile. A implementação padrão do Motif é x11-toolkits/open-motif. Os usuários podem escolher o x11-toolkits/lesstif em vez disso, definindo WANT_LESSTIF no seu make.conf. O MOTIFLIB será definido por motif.mk para referenciar a biblioteca Motif apropriada. Por favor, corrija o fonte do port para usar ${MOTIFLIB} onde quer que a biblioteca Motif seja referenciada no Makefile original ou no Imakefile. Existem dois casos comuns: Se o port se referir à biblioteca Motif como -lXm em seu Makefile ou Imakefile, substitua ${MOTIFLIB} por isso. Se o port usa XmClientLibs em seu Imakefile, mude para ${MOTIFLIB} ${XTOOLLIB} ${XLIB}. Observe que o MOTIFLIB (geralmente) se expande para -L/usr/local/lib -lXm -lXp ou /usr/local/lib/libXm.a, então não há necessidade de adicionar -L ou -l na frente. Fontes X11 Se o port instalar fontes para o X Window System, coloque-as em LOCALBASE/lib/X11/fontes/local. Obtendo um <envar>DISPLAY</envar> Falso com Xvfb Algumas aplicações requerem uma tela X11 funcional para que a compilação seja bem-sucedida. Isso representa um problema para as máquinas que operam sem um monitor. Quando essa variável é usada, a infraestrutura de compilação iniciará o X virtual framebuffer. Um DISPLAY funcional é então passado para a compilação. Veja USES=exibição para os possíveis argumentos. USES= display Entradas de Desktop Entradas de desktop (um padrão Freedesktop) fornecem uma maneira de ajustar automaticamente os recursos do desktop quando um novo programa é instalado, sem a necessidade de intervenção do usuário. Por exemplo, programas recém-instalados aparecem automaticamente nos menus de aplicativos de ambientes de desktop compatíveis. Entradas de Desktop surgiram no ambiente de desktop GNOME, mas agora são um padrão e também funcionam com o KDE e o Xfce. Esta pitada de automação fornece um benefício real para o usuário, e as entradas de desktop são incentivadas para aplicativos que podem ser usados ​​em um ambiente desktop. Usando Arquivos <filename>.desktop</filename> Pré-definidos Ports que incluem *.desktop pré-definidos devem incluir estes arquivos no pkg-plist e instalá-los no diretório $LOCALBASE/share/applications. A macro INSTALL_DATA é útil para instalar esses arquivos. Atualizando o Banco de Dados do Desktop Se um port tiver uma entrada MimeType em seu portname.desktop, o banco de dados do desktop deve ser atualizado após a instalação e desinstalação. Para fazer isso, defina USES= desktop-file-utils. Criando Entradas de Desktop com <varname>DESKTOP_ENTRIES</varname> As entradas desktop podem ser facilmente criadas para aplicativos usando DESKTOP_ENTRIES. Um arquivo chamado name.desktop será criado, instalado e adicionado ao pkg-plist automaticamente. A sintaxe é: DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify A lista de possíveis categorias está disponível no Site Freedesktop. StartupNotify indica se a aplicação é compatível com notificações de inicialização. Estes são tipicamente um indicador gráfico como um relógio que aparece no ponteiro do mouse, menu ou painel para dar ao usuário uma indicação quando um programa está sendo iniciado. Um programa que seja compatível com as notificações de inicialização limpa o indicador depois de iniciado. Programas que não são compatíveis com as notificações de inicialização nunca limpariam o indicador (possivelmente confundindo e enfurecendo o usuário) e devem ter StartupNotify definido como false então o indicador não é mostrado. Exemplo: DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \ "${DATADIR}/xtra/graf/tome-128.png" \ "tome -v -g" "Application;Game;RolePlaying;" \ false Usando o GNOME Introdução Este capítulo explica a estrutura do framework GNOME utilizado pelos ports. O framework pode ser dividido livremente nos componentes base, componentes desktop GNOME e algumas macros especiais que simplificam o trabalho dos mantenedores dos ports. Ao desenvolver um port ou modificar um, por favor, defina DEVELOPER=yes no ambiente ou em /etc/make.conf. Isso faz com que o framework do ports ative verificações adicionais. Usando <varname>USE_GNOME</varname> Adicionar esta variável ao port permite o uso das macros e componentes definidos em bsd.gnome.mk. O código em bsd.gnome.mk adiciona as dependências de tempo de compilação, tempo de execução ou biblioteca necessárias ou o tratamento de arquivos especiais. Aplicativos GNOME sob o FreeBSD usam o framework USE_GNOME. Inclua todos os componentes necessários como uma lista separada por espaço. Os componentes USE_GNOME são divididos nessas listas virtuais: componentes básicos, componentes do GNOME 3 e componentes legados. Se o port precisa apenas de bibliotecas GTK3, este é o caminho mais curto para defini-lo: USE_GNOME= gtk30 Componentes USE_GNOME adicionam automaticamente as dependências de que precisam. Por favor, veja para uma lista exaustiva de todos componentes USE_GNOME e quais outros componentes eles implicam e suas dependências. Aqui está um exemplo de Makefile para um port do GNOME que usa muitas das técnicas descritas neste documento. Por favor, use-o como um guia para criar novos ports. # $FreeBSD$ PORTNAME= regexxer DISTVERSION= 0.10 CATEGORIES= devel textproc gnome MASTER_SITES= GNOME MAINTAINER= kwm@FreeBSD.org COMMENT= Interactive tool for performing search and replace operations USES= gettext gmake pathfix pkgconfig tar:xz GNU_CONFIGURE= yes USE_GNOME= gnomeprefix intlhack gtksourceviewmm3 CPPFLAGS+= -I${LOCALBASE}/include LDFLAGS+= -L${LOCALBASE}/lib INSTALLS_ICONS= yes GLIB_SCHEMAS= org.regexxer.gschema.xml .include <bsd.port.mk> A macro USE_GNOME se utilizada sem nenhum argumento não irá adicionar nenhuma dependência ao port. O USE_GNOME não pode ser definido depois do bsd.port.pre.mk. Variáveis Esta seção explica quais macros estão disponíveis e como elas são usadas. Como elas são usadas no exemplo acima. A tem uma explicação mais detalhada. A variável USE_GNOME precisa ser definido para que essas macros sejam úteis. INSTALLS_ICONS Ports GTK+ que instalam ícones de estilo Freedesktop em ${LOCALBASE}/share/icons deve usar essa macro para garantir que os ícones sejam armazenados em cache e exibidos corretamente. O arquivo de cache é nomeado icon-theme.cache. Não inclua esse arquivo em pkg-plist. Essa macro manipula isso automaticamente. Esta macro não é necessária para Qt, que usam um método interno. GLIB_SCHEMAS Lista de todos os arquivos de esquema de glib que o port instala. A macro adicionará os arquivos ao plist do port e manipulará o registro destes arquivos na instalação e desinstalação. Os arquivos de esquema do glib são escritos em XML e terminam com a extensão gschema.xml. Eles estão instalados no diretório share/glib-2.0/schemas/. Esses arquivos de esquema contêm todos os valores de configuração do aplicativo com as configurações padrão. O banco de dados real usado pelos aplicativos é construído por glib-compile-schema, que é executado pela macro GLIB_SCHEMAS. GLIB_SCHEMAS=foo.gschema.xml Não adicione esquemas simplificados ao pkg-plist. Se eles estão listados em pkg-plist, eles não serão registrados e os aplicativos podem não funcionar corretamente. GCONF_SCHEMAS Liste todos os arquivos do esquema gconf. A macro adicionará os arquivos de esquema ao plist do port e manipulará seu registro na instalação e desinstalação. O GConf é o banco de dados baseado em XML que praticamente todos os aplicativos GNOME usam para armazenar suas configurações. Esses arquivos são instalados no banco de dados no diretório etc/gconf/schemas. Esse banco de dados é definido pelos arquivos de esquema instalados que são usados ​​para gerar os arquivos chave %gconf.xml. Para cada arquivo de esquema instalado pelo port, existe uma entrada no Makefile: GCONF_SCHEMAS=my_app.schemas my_app2.schemas my_app3.schemas Os esquemas do Gconf estão listados na macro GCONF_SCHEMAS em vez do pkg-plist. Se eles estiverem listados em pkg-plist, eles não serão registrados e os aplicativos podem não funcionar corretamente. INSTALLS_OMF Os arquivos do Open Source Metadata Framework (OMF) são comumente usados ​​pelos aplicativos GNOME 2. Esses arquivos contêm as informações do arquivo de ajuda do aplicativo e requerem processamento especial pelo ScrollKeeper/rarian. Para registrar adequadamente arquivos OMF ao instalar aplicativos GNOME a partir de pacotes, certifique-se de que os arquivos omf estão listados em pkg-plist e que o Makefile do port tem o INSTALLS_OMF definido: INSTALLS_OMF=yes Quando definido, bsd.gnome.mk digitaliza automaticamente o pkg-plist e adiciona diretivas @exec e @unexec para cada .omfpara rastrear no banco de dados de registro do OMF. Componentes GNOME Para mais ajuda com um port GNOME, veja alguns dos ports existentes por exemplo. A pagina GNOME do FreeBSD tem informações de contato, se precisar de mais ajuda. Os componentes são divididos em componentes GNOME que estão atualmente em uso e componentes legados. Se o componente suportar argumento, eles serão listados entre parênteses na descrição. O primeiro é o padrão. "Ambos" são mostrados se o componente usar como padrão a adição às dependências de construção e execução. Componentes GNOME Componente Programa associado Descrição atk accessibility/atk Kit de ferramentas de acessibilidade (ATK) atkmm accessibility/atkmm c++ bindings para atk cairo graphics/cairo Biblioteca de gráficos vetoriais com suporte a saída entre dispositivos cairomm graphics/cairomm c++ bindings para o cairo dconf devel/dconf Sistema de banco de dados de configuração (both, buil, run) evolutiondataserver3 databases/evolution-data-server Backends de dados para a suíte mail/PIM integrada do Evolution gdkpixbuf2 graphics/gdk-pixbuf2 Biblioteca de gráficos para GTK+ glib20 devel/glib20 Biblioteca core do GNOMEglib20 glibmm devel/glibmm c++ bindings para glib20 gnomecontrolcenter3 sysutils/gnome-control-center Centro de Controle do GNOME 3 gnomedesktop3 x11/gnome-desktop Biblioteca de interface do usuário do desktop GNOME 3 gsound audio/gsound Biblioteca GObject para reproduzir sons do sistema (both, build, run) gtk-update-icon-cache graphics/gtk-update-icon-cache Utilitário Gtk-update-icon-cache do kit de ferramentas Gtk + gtk20 x11-toolkits/gtk20 Kit de ferramentas Gtk+ 2 gtk30 x11-toolkits/gtk30 Kit de ferramentas Gtk+ 3 gtkmm20 x11-toolkits/gtkmm20 c++ bindings 2.0 para o kit de ferramentas gtk20 gtkmm24 x11-toolkits/gtkmm24 c++ bindings 2.4 para o kit de ferramentas gtk20 gtkmm30 x11-toolkits/gtkmm30 c++ bindings 3.0 para o kit de ferramentas gtk30 gtksourceview2 x11-toolkits/gtksourceview2 Widget que adiciona destaque de sintaxe para o GtkTextView gtksourceview3 x11-toolkits/gtksourceview3 Widget de texto que adiciona destaque de sintaxe ao widget GtkTextView gtksourceviewmm3 x11-toolkits/gtksourceviewmm3 c++ bindings para a biblioteca gtksourceview3 gvfs devel/gvfs Sistema de arquivos virtual do GNOME intltool textproc/intltool Ferramenta para Internacionalização (veja também intlhack) introspection devel/gobject-introspection Ligações de introspecção e ferramentas básicas para gerar ligações de introspecção. Na maioria das vezes: build é suficiente, e :both/:run só é necessário para aplicativos que usam ligações de introspecção. (both, build, run) libgda5 databases/libgda5 Fornece acesso uniforme a diferentes tipos de fontes de dados libgda5-ui databases/libgda5-ui Biblioteca de interface do usuário da biblioteca libgda5 libgdamm5 databases/libgdamm5 c++ bindings para a biblioteca libgda5 libgsf devel/libgsf Abstração extensível de I/O para lidar com formatos de arquivo estruturados librsvg2 graphics/librsvg2 Biblioteca para analisar e renderizar arquivos gráficos vetoriais SVG libsigc++20 devel/libsigc++20 Framework de Callback para C++ libxml++26 textproc/libxml++26 c++ bindings para a biblioteca libxml2 libxml2 textproc/libxml2 Biblioteca do parser XML (both, build, run) libxslt textproc/libxslt Biblioteca XSLT C (both, build, run) metacity x11-wm/metacity Gerenciador de janelas do GNOME nautilus3 x11-fm/nautilus Gerenciador de arquivos GNOME pango x11-toolkits/cave Estrutura de código aberto para o layout e renderização do texto i18n pangomm x11-toolkits/pangomm c++ bindings para a biblioteca pango py3gobject3 devel/py3-gobject3 Python 3, GObject 3.0 bindings pygobject3 devel/py-gobject3 Python 2, GObject 3.0 bindings vte3 x11-toolkits/vte3 Widget de terminal com melhor acessibilidade e suporte I18N
Componentes Macro do GNOME Componente Descrição gnomeprefix Forneça configure com alguns locais padrão. intlhack O mesmo que intltool, porém com os patches necessários para garantir o share/locale/. Por favor, use somente quando intltool sozinho não for suficiente. referencehack Esta macro existe para ajudar a dividir a API ou a documentação de referência em seu próprio port.
Componentes Legados do GNOME Componente Programa associado Descrição atspi accessibility/at-spi Interface do Provedor de Serviços de Tecnologia Assistiva esound audio/esound Pacote de som do Enlightenment gal2 x11-toolkits/gal2 Coleção de widgets obtidos do GNOME 2 gnumeric gconf2 devel/gconf2 Sistema de banco de dados de configuração para o GNOME 2 gconfmm26 devel/gconfmm26 c++ bindings para o gconf2 gdkpixbuf graphics/gdk-pixbuf Biblioteca de gráficos para GTK+ glib12 devel/glib12 biblioteca principal glib 1.2 gnomedocutils textproc/gnome-doc-utils Utilitários de documentação para o GNOME gnomemimedata misc/gnome-mime-data MIME e banco de dados de aplicativos para o GNOME 2 gnomesharp20 x11-toolkits/gnome-sharp20 Interfaces do GNOME 2 para o tempo de execução do .NET gnomespeech accessibility/gnome-speech API de conversão de texto em voz do GNOME 2 gnomevfs2 devel/gnome-vfs Sistema de Arquivos Virtual do GNOME 2 gtk12 x11-toolkits/gtk12 Kit de ferramentas Gtk+ 1.2 gtkhtml3 www/gtkhtml3 Mecanismo leve de renderização/impressão/edição de HTML gtkhtml4 www/gtkhtml4 Mecanismo leve de renderização/impressão/edição de HTML gtksharp20 x11-toolkits/gtk-sharp20 Interfaces GTK+ e GNOME 2 para o runtime .NET gtksourceview x11-toolkits/gtksourceview Widget que adiciona destaque de sintaxe para o GtkTextView libartgpl2 graphics/libart_lgpl Biblioteca para gráficos 2D de alto desempenho libbonobo devel/libbonobo Componente e sistema de documentos compostos para o GNOME 2 libbonoboui x11-toolkits/libbonoboui GUI frontend para o componente libbonobo do GNOME 2 libgda4 databases/libgda4 Fornece acesso uniforme a diferentes tipos de fontes de dados libglade2 devel/libglade2 Biblioteca glade do GNOME 2 libgnome x11/libgnome Bibliotecas para o GNOME 2, um ambiente de desktop GNU libgnomecanvas graphics/libgnomecanvas Biblioteca Gráfica para o GNOME 2 libgnomekbd x11/libgnomekbd Biblioteca compartilhada de teclado do GNOME 2 libgnomeprint print/libgnomeprint Biblioteca de suporte de impressão do Gnome 2 libgnomeprintui x11-toolkits/libgnomeprintui Biblioteca de suporte de impressão do Gnome 2 libgnomeui x11-toolkits/libgnomeui Bibliotecas para a GUI do GNOME 2, um ambiente de desktop GNU libgtkhtml www/libgtkhtml Mecanismo leve de renderização/impressão/edição de HTML libgtksourceviewmm x11-toolkits/libgtksourceviewmm c++ binding do GtkSourceView libidl devel/libIDL Biblioteca para criação de árvores de arquivo do CORBA IDL libsigc++12 devel/libsigc++12 Framework de Callback para C++ libwnck x11-toolkits/libwnck Biblioteca usada para escrever pagers e listas de tarefas libwnck3 x11-toolkits/libwnck3 Biblioteca usada para escrever pagers e listas de tarefas orbit2 devel/ORBit2 CORBA ORB de alto desempenho com suporte para a linguagem C pygnome2 x11-toolkits/py-gnome2 Python bindings para GNOME 2 pygobject devel/py-gobject Python 2, GObject 2.0 bindings pygtk2 x11-toolkits/py-gtk2 Conjunto de Python bindings para GTK+ pygtksourceview x11-toolkits/py-gtksourceview Python bindings para GtkSourceView 2 vte x11-toolkits/vte Widget de terminal com melhor acessibilidade e suporte I18N
Componentes Obsoletos: Não Use Componente Descrição pangox-compat O pangox-compatfoi descontinuado e separado do pacote pango.
Usando o Qt Ports que requerem o Qt A coleção de ports fornece suporte para o Qt 5 com USES+=qt:5. Configure o USE_QT para a lista de componentes obrigatórios do Qt (bibliotecas, ferramentas, plugins). O framework Qt exporta um número de variáveis ​​que podem ser usadas por ports, algumas delas listadas abaixo: Variáveis ​​Fornecidas aos Ports Que Usam o Qt QMAKE Caminho completo para o binário qmake. LRELEASE Caminho completo para utilitário Irelease. MOC Caminho completo para moc RCC Caminho completo para rcc UIC Caminho completo para uic QT_INCDIR Diretório include Qt. QT_LIBDIR Caminho das bibliotecas Qt. QT_PLUGINDIR Caminho de plugins do Qt.
Seleção de Componentes As dependências individuais das ferramentas e da biblioteca Qt devem ser especificadas em USE_QT. Todo componente pode ser sufixado com _build ou _run, o sufixo indica se a dependência no componente está no tempo de compilação ou no tempo de execução. Se um sufixo não for usado, a dependência do componente será tanto em tempo de compilação quanto em tempo de execução. Geralmente, os componentes da biblioteca são especificados como unsuffixed, os componentes das ferramentas são especificados com o sufixo _build e os componentes dos plugins são especificados com o sufixo _run. Os componentes mais comumente usados estão listados abaixo (todos os componentes disponíveis estão listados em _USE_QT_ALL e _USE_QT5_ONLY em /usr/ports/Mk/Uses/qt.mk): Componentes da Biblioteca Qt Disponíveis Nome Descrição 3d Módulo Qt3D assistant Navegador de documentação do Qt 5 canvas3d Módulo Qt canvas3d charts Módulo de gráficos Qt 5 concurrent Módulo multi-threading Qt connectivity Módulo de conectividade Qt (Bluetooth/NFC) core Módulo não-gráfico do núcleo Qt datavis3d Módulo de visualização de dados 3D Qt 5 dbus Módulo de comunicação entre processos Qt D-Bus declarative Framework declarativo Qt para interfaces dinâmicas de usuário designer Designer gráfico de interface de usuário do Qt 5 diag Ferramenta para relatar informações de diagnóstico sobre o Qt e seu ambiente doc Documentação do Qt 5 examples Código-fonte dos exemplos do Qt 5 gamepad Módulo de Gamepad Qt 5 graphicaleffects Efeitos gráficos rápidos do Qt gui Módulo de interface gráfica do usuário do Qt help Módulo de integração de ajuda on-line do Qt l10n Mensagens localizadas do Qt linguist Ferramenta de tradução do Qt 5 location Módulo de localização do Qt multimedia Módulo de suporte de áudio, vídeo, rádio e câmera do Qt network Módulo de rede do Qt networkauth Módulo de autenticação de rede do Qt opengl Módulo de suporte OpenGL compatível com o Qt 5 paths Cliente de linha de comando para QStandardPaths phonon4 Framework de multimídia do KDE pixeltool Lupa de tela do Qt 5 plugininfo Dumper de metadados do plugin Qt5 printsupport Módulo de suporte de impressão do Qt qdbus Interface de linha de comando do Qt para o D-Bus qdbusviewer Interface gráfica do Qt 5 para o D-Bus qdoc Gerador de documentação do Qt qdoc-data Arquivos de configuração do QDoc qev Ferramenta de introspecção de eventos Qt QWidget qmake Gerador de Makefile do Qt quickcontrols Conjunto de controles para construir interfaces completas no Qt Quick quickcontrols2 Conjunto de controles para construir interfaces completas no Qt Quick remoteobjects Módulo SXCML Qt5 script Módulo de script compatível com Qt 4 scripttools Componentes adicionais do Qt Script scxml Módulo SXCML Qt5 sensors Módulo de sensores do Qt serialbus Funções do Qt para acessar sistemas de bus industriais serialport Funções do Qt para acessar portas seriais speech Recursos de acessibilidade para o Qt5 sql Módulo de integração a banco de dados SQL do Qt sql-ibase Plugin de banco de dados InterBase/Firebird do Qt sql-mysql Plugin de banco de dados MySQL do Qt sql-odbc Plugin Qt para conectividade Open Database sql-pgsql Plugin de banco de dados do PostgreSQL do Qt sql-sqlite2 Plugin de banco de dados SQLite 2 do Qt sql-sqlite3 Plugin de banco de dados SQLite 3 do Qt sql-tds Plugin de conectividade ao banco de dados TDS do Qt svg Módulo de suporte SVT do Qt testlib Módulo de teste unitário do Qt uiplugin Interface de plug-in do Qt widget personalizado para o Qt Designer uitools Módulo de suporte a formulários de interface de usuário do Qt Designer virtualkeyboard Módulo de teclado virtual do Qt 5 wayland Qt5 wrapper para o Wayland webchannel Biblioteca Qt 5 para integração de C++/QML com clientes HTML/js webengine Biblioteca Qt 5 para renderizar conteúdo da web webkit QtWebKit com uma base de código WebKit mais moderna websockets Implementação do protocolo WebSocket do Qt websockets-qml Implementação do protocolo WebSocket do Qt (QML bindings) webview Componente do Qt para exibir o conteúdo da web widgets Módulo de widgets C++ do Qt x11extras Recursos específicos da plataforma Qt para sistemas baseados em X11 xml Implementações SAX e DOM do Qt xmlpatterns Suporte do Qt para XPath, XQuery, XSLT e XML Schema
Para determinar as bibliotecas das quais um aplicativo depende, execute o ldd no executável principal após uma compilação bem sucedida. Componentes Disponíveis da Ferramenta Qt Nome Descrição buildtools Ferramentas de compilação (moc, rcc), necessária para quase todas as aplicações do Qt. linguisttools ferramentas de localização: Irelease, lupdate qmake Utilitário gerador/compilador de Makefile
Componentes Disponíveis de Plugin Qt Nome Descrição imageformats plugins para formatos de imagem TGA, TIFF e MNG
Selecionando Componentes do Qt 5 Neste exemplo, o aplicativo portado usa a biblioteca de interface gráfica do usuário do Qt 5, a biblioteca principal do Qt 5, todas as ferramentas de geração de código do Qt 5 e o gerador de Makefile do Qt 5. Uma vez que a biblioteca gui implica na dependência da biblioteca principal, o core não precisa ser especificado. As ferramentas de geração de código do Qt 5 moc, uic e rcc, bem como o gerador de Makefile qmake são necessários apenas em tempo de compilação, assim eles são especificados com o sufixo _build: USES= qt:5 USE_QT= gui buildtools_build qmake_build Usando <command>qmake</command> Se o aplicativo fornecer um arquivo de projeto qmake (*.pro), defina USES=qmake junto com USE_QTx. Observe que USES=qmake já implica uma dependência de compilação no qmake, portanto, o componente qmake pode ser omitido de USE_QT. Igual ao CMake, o qmake suporta compilações out-of-source, que podem ser ativadas especificando o argumento outsource (verUSES=qmakeexemplo) . Argumentos Possíveis para <literal>USES= qmake</literal> Variável Descrição no_configure Não adicione o target configure. Isso é implícito pelo HAS_CONFIGURE=yes e GNU_CONFIGURE=yes. Isso é requerido quando a compilação apenas precisa do ambiente de setup do USES= qmake, e dessa forma, executa-se o qmake por si próprio. no_env Suprime modificações dos ambientes configure e make. É necessário somente quando qmake é usado para configurar o software e a compilação falha em entender a configuração do ambiente pelo USES= qmake. norecursive Não passe o argumento -recursive para o qmake. outsource Realiza uma compilação out-of-source.
Variáveis ​​para Ports Que Usam o <command>qmake</command> Variável Descrição QMAKE_ARGS Flags específicas do port qmake a serem passadas para o binario do qmake. QMAKE_ENV Variáveis ​​de ambiente a serem definidas para o binario qmake. O padrão é ${CONFIGURE_ENV}. QMAKE_SOURCE_PATH Caminho para os arquivos de projeto do qmake (.pro). O padrão é ${WRKSRC} se uma compilação out-of-source for solicitada, caso contrário, deixe em branco.
Ao usar USES= qmake, estas configurações são implementadas: CONFIGURE_ARGS+= --with-qt-includes=${QT_INCDIR} \ --with-qt-libraries=${QT_LIBDIR} \ --with-extra-libs=${LOCALBASE}/lib \ --with-extra-includes=${LOCALBASE}/include CONFIGURE_ENV+= QTDIR="${QT_PREFIX}" QMAKE="${QMAKE}" \ MOC="${MOC}" RCC="${RCC}" UIC="${UIC}" \ QMAKESPEC="${QMAKESPEC}" PLIST_SUB+= QT_INCDIR=${QT_INCDIR_REL} \ QT_LIBDIR=${QT_LIBDIR_REL} \ QT_PLUGINDIR=${QT_PLUGINDIR_REL} Alguns scripts de configuração não suportam os argumentos acima. Para suprimir a modificação de CONFIGURE_ENV e CONFIGURE_ARGS defina USES= qmake:no_env. Exemplo <literal>USES= qmake</literal> Este trecho demonstra o uso do qmake para um port Qt 5: USES= qmake:outsource qt:5 USE_QT= buildtools_build Aplicações Qt são frequentemente escritas para serem multi-plataforma e muitas vezes o X11/Unix não é a plataforma em que são desenvolvidas, o que por sua vez leva a certas pontas soltas, como: Faltam caminhos de inclusão adicionais. Muitos aplicativos vêm com suporte ao ícone da bandeja do sistema, mas não buscam inclusões e/ou bibliotecas nos diretórios do X11. Para adicionar diretórios aos includes e bibliotecas de pesquisa do qmake através da linha de comando, use: QMAKE_ARGS+= INCLUDEPATH+=${LOCALBASE}/include \ LIBS+=-L${LOCALBASE}/lib Caminhos falsos de instalação. Às vezes, dados como ícones ou arquivos .desktop são instalados por padrão em diretórios que não são verificados por aplicativos compatíveis com XDG. O editors/texmaker é um exemplo disso - veja patch-texmaker.pro no diretório de arquivos desse port para um modelo sobre como remediar isso diretamente no arquivo de projeto qmake. Usando o KDE Definições de Variáveis ​​do KDE Se a aplicação depender do KDE, defina USES+=kde:5 e defina USE_KDE com a lista de componentes necessários. Sufixos _build e _run podem ser usados ​​para forçar o tipo de dependência de componentes (por exemplo, baseapps_run). Se nenhum sufixo for definido, o tipo padrão de dependência será usado. Para forçar os dois tipos, adicione o componente duas vezes com os dois sufixos (por exemplo, ecm_build ecm_run). Os componentes disponíveis estão listados abaixo (os componentes atualizados também estão listados em /usr/ports/Mk/Uses/kde.mk): Componentes Disponíveis do KDE Nome Descrição activities Biblioteca de tempo de execução do KF5 para organizar o trabalho em atividades separadas activities-stats Estatísticas do KF5 para atividades activitymanagerd Serviço do sistema para gerenciar atividades do usuário, rastrear os padrões de uso akonadi Servidor de armazenamento para o KDE-Pim akonadicalendar Integração de Calendário do Akonadi akonadiconsole Console de gerenciamento e depuração do Akonadi akonadicontacts Bibliotecas e daemons para implementar o gerenciamento de contatos do Akonadi akonadiimportwizard Importa dados de outros clientes de email para o KMail akonadimime Bibliotecas e daemons para implementar o tratamento básico de email akonadinotes Biblioteca do KDE para acessar caixas postais no formato MBox akonadisearch Bibliotecas e daemons para implementar buscas no Akonadi akregator Um leitor de feeds do KDE alarmcalendar API do KDE para alarmes do KAlarm apidox Ferramentas de Documentação da API KF5 archive Biblioteca KF5 que fornece classes para lidar com formatos de arquivo attica Biblioteca da API do Open Collaboration Services do KDE 5 attica5 Biblioteca da API do Open Collaboration Services do KDE 5 auth Abstração do KF5 para funcionalidades de autenticação e políticas do sistema baloo KF5 Framework para pesquisar e gerenciar metadados do usuário baloo-widgets Biblioteca BalooWidgets baloo5 KF5 Framework para pesquisar e gerenciar metadados do usuário blog API do KDE para acesso ao weblogging bookmarks Biblioteca KF5 para bookmarks e para o formato XBEL breeze Arte, estilos e recursos do Plasma5 para o estilo visual Breeze breeze-gtk Estilo visual do Plasma5 Breeze para Gtk breeze-icons Tema de ícones do Breeze para o KDE calendarcore Biblioteca de acesso ao calendário do KDE calendarsupport Bibliotecas de suporte de calendário para o KDEPim calendarutils Utilitário KDE e funções da interface do usuário para acessar o calendário codecs Biblioteca KF5 para manipulação de string completion Assistentes e widgets de conclusão de texto do KF5 config Widgets do KF5 para diálogos de configuração configwidgets Widgets do KF5 para diálogos de configuração contacts Api do KDE para gerenciar informações de contato coreaddons Complementos do KF5 para o QtCore crash Biblioteca KF5 para lidar com análise de falhas e relatório de erros de aplicativos dbusaddons Complementos do KF5 para o QtDBus decoration Biblioteca do Plasma5 para criar decorações de janelas designerplugin Integração do KF5 para widgets de Framework no Qt Designer/Creator discover Ferramentas de gerenciamento de pacotes do Plasma5 dnssd Abstração do KF5 para os recursos do sistema DNSSD doctools Geração de documentação do KF5 a partir do docbook drkonqi Manipulador de falhas do Plasma5 ecm Módulos e scripts extras para o CMake emoticons Biblioteca KF5 para converter emoticons eventviews Bibliotecas de visualização de eventos para o KDEPim filemetadata Biblioteca KF5 para extrair metadados de arquivos frameworkintegration Espaço de trabalho e plugins de integração entre estruturas KF5 gapi Biblioteca baseada no KDE para acessar serviços do Google globalaccel Biblioteca KF5 para incluir suporte para atalhos do espaço de trabalho global grantlee-editor Editor para os temas de Grantlee grantleetheme KDE PIM grantleetheme gravatar Biblioteca para suporte a gravatar guiaddons Complementos do KF5 para o QtGui holidays Biblioteca do KDE para feriados do calendário hotkeys Biblioteca do Plasma5 para teclas de atalho i18n Framework avançado de internacionalização do KF5 iconthemes Biblioteca KF5 para manipular ícones em aplicativos identitymanagement Identidades do KDE pim idletime Biblioteca KF5 para monitorar a atividade do usuário imap API do KDE para suporte a IMAP incidenceeditor Bibliotecas do editor de incidências para o KDE Pim infocenter Utilidade do Plasma5 fornecendo informações do sistema init Iniciador de processos KF5 para acelerar o lançamento de aplicativos do KDE itemmodels Modelos KF5 para o sistema Qt Model / View itemviews KF5 widget addons para Qt Model/View jobwidgets Widgets do KF5 para rastrear a instância do KJob js Biblioteca KF5 que fornece um interpretador de script ECMA jsembed Biblioteca KF5 para ligar objetos JavaScript a QObjects kaddressbook Gerenciador de contatos do KDE kalarm Agendador de alarmes pessoal kalarm Agendador de alarmes pessoal kate Framework básico do editor para o sistema KDE kcmutils Utilitários KF5 para trabalhar com KCModules kde-cli-tools Ferramentas não interativas do sistema do Plasma5 kde-gtk-config Configurador Plasma5 GTK2 e GTK3 kdeclarative Biblioteca KF5 que prove a integração dos frameworks do QML e do KDE kded Daemon extensível do KF5 para fornecer serviços a nível do sistema kdelibs4support KF5 porting aid from KDELibs4 kdepim-addons Complementos do KDE PIM kdepim-apps-libs Bibliotecas do KDE PIM relacionadas ao correio kdepim-runtime5 Ferramentas e serviços do KDE PIM kdeplasma-addons Complementos do Plasma 5 para melhorar a experiência do Plasma kdesu Integração do KF5 com o su para privilégios elevados kdewebkit Biblioteca KF5 que fornece a integração do QtWebKit kgamma5 Configurações de gama do monitor Plasma5 khtml Motor de renderização KF5 KTHML kimageformats Biblioteca KF5 que fornece suporte para formatos de imagem adicionais kio Recurso e abstração de acesso à rede do KF5 kirigami2 Conjunto de componentes baseados em QtQuick kitinerary Modelo de dados e sistema de extração para informações de reservas de viagens kmail Cliente de correio do KDE kmail Cliente de correio do KDE kmail-account-wizard Assistente de conta de e-mail do KDE kmenuedit Editor de menu do Plasma5 knotes Notas pop-up kontact Gerenciador de Informações Pessoais do KDE kontact Gerenciador de Informações Pessoais do KDE kontactinterface Cola do KDE para incorporar KParts no Kontact korganizer Programa de calendário e agendamento kpimdav Uma implementação do protocolo DAV com KJobs kpkpass Biblioteca para lidar com pass files da Apple Wallet kross Aplicação de scripting multi-language do KF5 kscreen Biblioteca de gerenciamento de tela do Plasma5 kscreenlocker Arquitetura de tela de bloqueio seguro do Plasma5 ksmtp Biblioteca job-based para enviar email através de um servidor SMTP ksshaskpass Frontend ssh-add do Plasma5 ksysguard Utilitário Plasma5 para rastrear e controlar os processos em execução kwallet-pam Integração PAM do Plasma5 KWallet kwayland-integration Plugins de integração para um desktop baseado em Wayland kwin Gerenciador de janelas do Plasma5 kwrited Daemon do Plasma5 para ouvir paredes e escrever mensagens ldap API de acesso LDAP para o KDE libkcddb Biblioteca KDE CDDB libkcompactdisc Biblioteca do KDE para interfaceamento com CDs de áudio libkdcraw Interface LibRaw para o KDE libkdegames Bibliotecas usadas pelos jogos do KDE libkdepim Bibliotecas KDE PIM libkeduvocdocument Biblioteca para leitura e gravação de arquivos de vocabulário libkexiv2 Interface da biblioteca Exiv2 para o KDE libkipi Interface de Plugin de Imagem do KDE libkleo Gerenciador de certificados para o KDE libksane Interface da biblioteca SANE para o KDE libkscreen Biblioteca de gerenciamento de tela do Plasma5 libksieve Bibliotecas de inspeção para o KDEPim libksysguard Biblioteca do Plasma5 para rastrear e controlar processos em execução mailcommon Bibliotecas comuns para o KDEPim mailimporter Importar arquivos mbox para o KMail mailtransport Biblioteca do KDE para gerenciar o transporte de correio marble Globo virtual e atlas mundial para o KDE mbox Biblioteca do KDE para acessar caixas postais no formato MBox mbox-importer Importar arquivos mbox para o KMail mediaplayer Interface de plug-in do KF5 para recursos do media player messagelib Biblioteca para manipular mensagens milou Plasma5 Plasmóide para pesquisa mime Biblioteca para manipular dados MIME newstuff Biblioteca KF5 para baixar aplicativos da rede notifications Abstração KF5 para notificações do sistema notifyconfig Sistema de configuração KF5 para o KNotify okular Visualizador universal de documentos do KDE oxygen Estilo Oxygen Plasma5 oxygen-icons5 O tema de ícones do Oxygen para o KDE package Biblioteca KF5 para carregar e instalar pacotes parts Sistema de plugin centrado em documentos KF5 people Biblioteca KF5 para fornecer acesso a contatos pim-data-exporter Importar e exportar configurações do KDE PIM pimcommon Bibliotecas comuns para o KDEPim pimtextedit Biblioteca do KDE para utilitários de edição de texto específicos do PIM plasma-browser-integration Componentes do Plasma5 para integrar navegadores na área de trabalho plasma-desktop Área de trabalho plasma Plasma5 plasma-framework UI runtime baseado no plugin KF5 usado para escrever interfaces de usuários plasma-integration Plugins de integração do Qt Platform Theme para os workspaces do Plasma plasma-pa Misturador de áudio de pulso do Plasma5 Plasma plasma-sdk Aplicações do Plasma5 úteis para o desenvolvimento Plasma plasma-workspace Workspace Plasma5 Plasma plasma-workspace-wallpapers Plasma5 wallpapers plotting Framework de plotagem leve KF5 polkit-kde-agent-1 Daemon do Plasma5 que fornece uma interface de usuário de autenticação do polkit powerdevil Ferramenta Plasma5 para gerenciar as configurações de consumo de energia prison API para produzir códigos de barras pty Abstração KF5 pty purpose Oferece ações disponíveis para um propósito específico qqc2-desktop-style Estilo Qt QuickControl2 para o KDE runner Sistema de consulta paralelizado do KF5 service Plugin KF5 avançado e serviço de introspecção solid Integração e detecção de hardware do KF5 sonnet Biblioteca de verificação de ortografia baseada no plugin do KF5 syndication Biblioteca de manipulação de feeds do KDE syntaxhighlighting Mecanismo de destaque de sintaxe KF5 para texto e código estruturados systemsettings Configurações do sistema Plasma5 texteditor Editor avançado de texto embutido do KF5 textwidgets Widgets avançados do KF5 para edição de texto threadweaver Complementos do KF5 para o QtDBus tnef API do KDE para o tratamento de dados TNEF unitconversion Biblioteca KF5 para conversão de unidade user-manager Gerenciador de usuários do Plasma5 wallet Contêiner KF5 seguro e unificado para senhas de usuários wayland Wrapper da biblioteca KF5 Cliente e Servidor para as bibliotecas Wayland widgetsaddons Complementos do KF5 para o QtWidgets windowsystem Biblioteca KF5 para acesso ao sistema de janelas xmlgui Janelas principais configuráveis pelo usuário do KF5 xmlrpcclient Interação KF5 com serviços XMLRPC
Exemplo <varname>USE_KDE</varname> Este é um exemplo simples para um port do KDE. O USES= cmake instrui o port a utilizar o CMake, uma ferramenta de configuração amplamente usada pelos projetos do KDE (veja para informações detalhadas sobre o uso). O USE_KDE informa a dependência das bibliotecas do KDE. Os componentes necessários do KDE e outras dependências podem ser determinadas através do log de configuração. O USE_KDE não implica no USE_QT. Se um port requer alguns componentes do Qt, especifique-os em USE_QT. USES= cmake kde:5 qt:5 USE_KDE= ecm USE_QT= core buildtools_build qmake_build Usando o LXQt As aplicações que dependem do LXQt devem definir USES+= lxqt e definir a variável USE_LXQT para a lista de componentes necessários da tabela abaixo Componentes disponíveis do LXQt Nome Descrição buildtools Auxiliares para módulos CMake adicionais libfmqt Libfm Qt bindings lxqt LXQt core library qtxdg Implementação do Qt das especificações do XDG do freedesktop.org
Exemplo <literal>USE_LXQT</literal> Este é um exemplo simples, USE_LXQT adiciona uma dependência em bibliotecas LXQt. Os componentes necessários do LXQt e outras dependências podem ser determinados a partir do log de configuração. USES= cmake lxqt qt:5 tar:xz USE_QT= core dbus widgets buildtools_build qmake_build USE_LXQT= buildtools libfmqt Usando Java Definições de Variáveis Se o port precisar de um Java™ Development Kit (JDK) para compilar, executar ou até mesmo extrair o distfile, então defina USE_JAVA. Existem vários JDKs na coleção de ports, de vários fornecedores e em várias versões. Se o port precisar usar uma versão específica, especifique-a usando a variável JAVA_VERSION. A versão mais atual é java/openjdk8, java/openjdk6 e java/openjdk7 também estão disponíveis. Variáveis ​​Que Podem ser Definidas por Ports Que Usam Java Variável Significa USE_JAVA Defina para as variáveis ​​restantes para ter algum efeito. JAVA_VERSION Lista das versões Java adequadas separadas por espaço para o port. Um opcional "+" permite especificar um intervalo de versões (valores permitidos: 1.5[+] 1.6[+] 1.7[+]). JAVA_OS Lista de sistemas operacionais adequados do port JDK separados por espaço para o port (valores permitidos: native linux) JAVA_VENDOR Lista de fornecedores adequados de ports JDK separados por espaços para o port (valores permitidos: freebsd bsdjava sun openjdk) JAVA_BUILD Quando definido, adiciona o port JDK selecionado às dependências de compilação. JAVA_RUN Quando definido, adicione o port JDK selecionado às dependências de execução. JAVA_EXTRACT Quando definido, adicione o port JDK selecionado às dependências de extração.
Abaixo está a lista de todas as configurações que um port receberá após a configuração de USE_JAVA: Variáveis ​​Fornecidas para Ports que Usam Java Variável Valor JAVA_PORT O nome do port do JDK (por exemplo,java/openjdk6) JAVA_PORT_VERSION A versão completa do port do JDK (por exemplo,1.6.0). Somente os dois primeiros dígitos deste número de versão são necessários, use ${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/} JAVA_PORT_OS O sistema operacional usado pelo port do JDK (por exemplo, 'native') JAVA_PORT_VENDOR O fornecedor do port JDK (por exemplo,'openjdk') JAVA_PORT_OS_DESCRIPTION Descrição do sistema operacional usado pelo port JDK (por exemplo, 'Native') JAVA_PORT_VENDOR_DESCRIPTION Descrição do fornecedor do port JDK (por exemplo,'OpenJDK BSD Porting Team') JAVA_HOME Caminho para o diretório de instalação do JDK (por exemplo, '/usr/local/openjdk6') JAVAC Caminho para o compilador Java (por exemplo, '/usr/local/openjdk6/bin/javac'). JAR Caminho para ferramenta jar a ser usada (por exemplo, '/usr/local/openjdk6/bin/jar' ou '/usr/local/bin/fastjar'). APPLETVIEWER Caminho para o utilitário appletviewer (por exemplo,'/usr/local/openjdk6/bin/appletviewer'). JAVA Caminho para o executável Java. Use isto para executar programas Java (por exemplo, '/usr/local/openjdk6/bin/java'). JAVADOC Caminho para o utilitário javadoc. JAVAH Caminho para o programa javah. JAVAP Caminho para o programa javap. JAVA_KEYTOOL Caminho para o utilitário keytool. JAVA_N2A Caminho para a ferramenta native2ascii. JAVA_POLICYTOOL Caminho para o programa policytool. JAVA_SERIALVER Caminho para o utilitário serialver. RMIC Caminho para o gerador de stub/skeleton RMI, rmic. RMIREGISTRY Caminho para o programa de registro RMI, rmiregistry. RMID Caminho para o daemon do RMI rmid. JAVA_CLASSES Caminho para o arquivo que contém os arquivos de classe do JDK, ${JAVA_HOME}/jre/lib/rt.jar.
Use o java-debug make target para obter informações para depurar o port. Ele exibirá o valor de muitas das variáveis ​​listadas anteriormente. Além disso, essas constantes são definidas para que todos os ports Java possam ser instalados de maneira consistente: Constantes definidas para os ports que usam Java Constante Valor JAVASHAREDIR O diretório base para tudo relacionado ao Java. Padrão: ${PREFIX}/share/java. JAVAJARDIR O diretório onde os arquivos JAR são instalados. Padrão: ${JAVASHAREDIR}/classes. JAVALIBDIR O diretório onde os arquivos JAR instalados por outros ports estão localizados. Padrão: ${LOCALBASE}/share/java/classes.
As entradas relacionadas são definidas em ambos PLIST_SUB (documentado em ) e SUB_LIST. Compilando com Ant Quando o port deve ser compilado usando o Apache Ant, ele deve definir USE_ANT. Ant é, portanto, considerado o comando sub-make. Quando nenhum target do-build é definido pelo port, será definido um padrão que execute Ant de acordo com MAKE_ENV, MAKE_ARGS e ALL_TARGET. Isso é semelhante ao mecanismo USES=gmake, documentado em . Melhores Práticas Ao portar uma biblioteca Java, o port precisa instalar o(s) arquivo(s) JAR em ${JAVAJARDIR} e o resto em ${JAVASHAREDIR}/${PORTNAME} (exceto para a documentação, veja abaixo). Para reduzir o tamanho do arquivo de empacotamento, faça referência aos arquivos JAR diretamente no Makefile. Use esta declaração (onde myport.jar é o nome do arquivo JAR instalado como parte do port): PLIST_FILES+= ${JAVAJARDIR}/myport.jar Ao portar um aplicativo Java, o port geralmente instala tudo em um único diretório (incluindo suas dependências JAR). O uso de ${JAVASHAREDIR}/${PORTNAME} é fortemente indicado neste caso. Cabe ao mantenedor do port decidir se o port instala as dependências JAR adicionais sob esse diretório ou utiliza as já instaladas (de ${JAVAJARDIR}). Ao portar um aplicativo Java que requer um servidor de aplicação, como o www/tomcat7 para executar o serviço, é bastante comum que o fornecedor distribua um .war. Um .war é uma aplicação Web ARchive a qual é extraído quando chamado pelo aplicativo. Evite adicionar um .war no pkg-plist. Isto não é considerado a melhor prática. Um servidor de aplicação irá expandir o arquivo war mas não irá remove-lo se o port for desinstalado. Uma forma mais desejável de trabalhar com este arquivo é extrair o seu conteudo, depois instalar os arquivos e, por fim, adicionar esses arquivos ao pkg-plist. TOMCATDIR= ${LOCALBASE}/apache-tomcat-7.0 WEBAPPDIR= myapplication post-extract: @${MKDIR} ${WRKDIR}/${PORTDIRNAME} @${TAR} xf ${WRKDIR}/myapplication.war -C ${WRKDIR}/${PORTDIRNAME} do-install: cd ${WRKDIR} && \ ${INSTALL} -d -o ${WWWOWN} -g ${WWWGRP} ${TOMCATDIR}/webapps/${PORTDIRNAME} cd ${WRKDIR}/${PORTDIRNAME} && ${COPYTREE_SHARE} \* ${WEBAPPDIR}/${PORTDIRNAME} Independentemente do tipo de port (biblioteca ou aplicativo), a documentação adicional é instalada na mesma localização como para qualquer outro port. A ferramenta Javadoc é conhecida por produzir um conjunto diferente de arquivos, dependendo da versão do JDK utilizado. Para ports que não impõem o uso de um determinado JDK, é uma tarefa complexa especificar a lista de empacotamento (pkg-plist). Esta é uma razão pela qual os mantenedores de ports são fortemente encorajados a usar PORTDOCS. Além disso, mesmo se o conjunto de arquivos que serão gerados pelo javadoc puder ser previsto, o tamanho do pkg-plist resultante irá encorajar o uso do PORTDOCS. O valor padrão para DATADIR é ${PREFIX}/share/${PORTNAME}. É uma boa ideia sobreescrever DATADIR para ${JAVASHAREDIR}/${PORTNAME} para ports Java. De fato, DATADIR é automaticamente adicionado a PLIST_SUB (documentado em) então use %%DATADIR%% diretamente em pkg-plist. Quanto à escolha de compilar ports Java a partir do código fonte ou instalar diretamente a partir de uma distribuição binária, não há política definida no momento da escrita deste livro. No entanto, os membros do Projeto Java do FreeBSD encorajam os mantenedores de ports a terem seus ports compilados a partir do código fonte sempre que for possível. Todos os recursos que foram apresentados nesta seção são implementados em bsd.java.mk. Se o port precisar de suporte Java mais sofisticado, por favor, primeiro dê uma olhada no log do bsd.java.mk no Subversion pois normalmente leva algum tempo para documentar os recursos mais recentes. Então, se o suporte necessário que estiver faltando for benéfico para muitos outros ports Java, sinta-se à vontade para discuti-lo na Lista de discussão do FreeBSD sobre Linguagem Java. Embora haja uma categoria Java para PRs, isso refere-se ao esforço de portabilidade do JDK do projeto Java do FreeBSD. Portanto, envie o port Java na categoria ports como para qualquer outro port, a menos que o problema esteja relacionado a uma implementação do JDK ou ao bsd.java.mk. Da mesma forma, existe uma política definida sobre as CATEGORIAS de um port Java, que é detalhada em . Aplicações Web, Apache e PHP Apache Variáveis ​​para Ports Que Usam o Apache USE_APACHE O port requer o Apache. Valores possíveis: yes (obtém qualquer versão), 22, 24, 22 a 24, 22+, etc. A versão padrão do APACHE é 22. Mais detalhes estão disponíveis em ports/Mk/bsd.apache.mk e em wiki.freebsd.org/Apache/. APXS Caminho completo para o binário apxs. Pode ser modificado no port. HTTPD Caminho completo para o binário httpd. Pode ser modificado no port. APACHE_VERSION A versão da instalação atual do Apache (variável somente leitura). Esta variável só está disponível após a inclusão de bsd.port.pre.mk. Valores possíveis: 22, 24. APACHEMODDIR Diretório para módulos Apache. Esta variável é automaticamente expandida em pkg-plist. APACHEINCLUDEDIR Diretório para cabeçalhos Apache. Esta variável é automaticamente expandida em pkg-plist. APACHEETCDIR Diretório para arquivos de configuração do Apache. Esta variável é automaticamente expandida em pkg-plist.
Variáveis ​​Úteis para Portar Módulos do Apache MODULENAME Nome do módulo. O valor padrão é PORTNAME. Exemplo: mod_hello SHORTMODNAME Nome abreviado do módulo. Automaticamente derivado de MODULENAME, mas pode ser substituído. Exemplo: hello AP_FAST_BUILD Use o apxs para compilar e instalar o módulo. AP_GENPLIST Também cria automaticamente um pkg-plist. AP_INC Adiciona um diretório ao caminho de pesquisa de cabeçalhos durante a compilação. AP_LIB Adiciona um diretório ao caminho de pesquisa de bibliotecas durante a compilação. AP_EXTRAS Flags adicionais para passar para o apxs.
Aplicações Web Aplicações web devem ser instaladas em PREFIX/www/appname. Este caminho está disponível tanto no Makefile quanto no pkg-plist como WWWDIR e o caminho relativo para PREFIX está disponível no Makefile como WWWDIR_REL. O usuário e o grupo do processo do servidor web estão disponíveis como WWWOWN e WWWGRP, no caso de a propriedade de alguns arquivos precisar ser alterada. Os valores padrão de ambos são www. Use WWWOWN?=myuser e WWWGRP?=mygroup se o port precisar de valores diferentes. Isso permite ao usuário substituí-los facilmente. Use WWWOWN e WWWGRP com moderação. Lembre-se de que todos os arquivos para os quais o servidor web tem permissão de escrita, são um risco de segurança esperando para acontecer. Não insira o Apache como dependência, a menos que o aplicativo web precise explicitamente do Apache. Respeite que os usuários podem desejar executar um aplicativo web em um servidor web diferente do Apache. PHP Aplicações PHP declaram sua dependência a ele com USES=php. Veja para maiores informações. Módulos PEAR Portar módulos PEAR é um processo muito simples. Adicione USES=pear ao Makefile do port. O framework instalará os arquivos relevantes nos lugares certos e gerará automaticamente a lista no momento da instalação. Exemplo de Makefile para Classes PEAR PORTNAME= Date DISTVERSION= 1.4.3 CATEGORIES= devel www pear MAINTAINER= example@domain.com COMMENT= PEAR Date and Time Zone Classes USES= pear .include <bsd.port.mk> Os módulos PEAR serão automaticamente flavorizados usando PHPflavors. Se um PEAR_CHANNEL não padrão for usado, as dependências de compilação e de tempo de execução serão automaticamente adicionadas. Módulos PEAR não precisam definir PKGNAMESUFFIX, é preenchido automaticamente usando PEAR_PKGNAMEPREFIX. Se um port precisar adicionar PKGNAMEPREFIX, também deve usar PEAR_PKGNAMEPREFIX para diferenciar entre diferentes flavors. Módulos <application>Horde</application> Da mesma forma, portar módulos Horde é um processo simples. Adicione USES=horde ao Makefile do port . O framework instalará os arquivos relevantes nos lugares certos e gerará automaticamente a lista no momento da instalação. As variáveis USE_HORDE_BUILD e USE_HORDE_RUN ​​podem ser usadas para adicionar dependências de tempo de compilação e de tempo de execução em outros módulos Horde. Veja Mk/Uses/horde.mk para uma lista completa dos módulos disponíveis. Exemplo de Makefile para Módulos <application>Horde</application> PORTNAME= Horde_Core DISTVERSION= 2.14.0 CATEGORIES= devel www pear MAINTAINER= horde@FreeBSD.org COMMENT= Horde Core Framework libraries OPTIONS_DEFINE= KOLAB SOCKETS KOLAB_DESC= Enable Kolab server support SOCKETS_DESC= Depend on sockets PHP extension USES= horde USE_PHP= session USE_HORDE_BUILD= Horde_Role USE_HORDE_RUN= Horde_Role Horde_History Horde_Pack \ Horde_Text_Filter Horde_View KOLAB_USE= HORDE_RUN=Horde_Kolab_Server,Horde_Kolab_Session SOCKETS_USE= PHP=sockets .include <bsd.port.mk> Como os módulos Horde também são módulos PEAR, eles também serão automaticamente aromatizados usando PHP flavors. Usando Python A Coleção de Ports suporta a instalação paralela de várias versões do Python. Os ports devem usar um interpretador python, de acordo com a configuração do usuário de PYTHON_VERSION. Mais proeminentemente, isso significa substituir o caminho para o executável python em scripts com o valor de PYTHON_CMD. Ports que instalam arquivos sob PYTHON_SITELIBDIR devem usar o prefixo pyXY- no prefixo do nome do pacote, assim o nome do pacote irá incorporar a versão do Python em que estão instalados. PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} Variáveis úteis para Ports que usam Python USES=python O port precisa do Python. A versão mínima necessária pode ser especificada com valores como 2.7+. Os intervalos de versão também podem ser especificados separando dois números de versão com um traço: USES=python:3.2-3.3 USE_PYTHON=distutils Use o distutils do Python para configurar, compilar e instalar. Isso é necessário quando o port vem com setup.py. Isso sobrescreve os targets do-build e do-install e também pode substituir do-configure se o GNU_CONFIGURE não estiver definido. Além disso, isso implica em USE_PYTHON=flavors. USE_PYTHON=autoplist Crie a lista de empacotamento automaticamente. Isso também requer que USE_PYTHON=distutils seja definido. USE_PYTHON=concurrent O port usará um prefixo exclusivo, normalmente PYTHON_PKGNAMEPREFIX para determinados diretórios, como EXAMPLESDIR e DOCSDIR e também irá acrescentar um sufixo, a versão python de PYTHON_VER, para os binários e scripts que serão instalados. Isso permite que os ports sejam instalados para diferentes versões do Python ao mesmo tempo, o que de outra forma instalaria arquivos conflitantes. USE_PYTHON=flavors O port não usa distutils, mas ainda suporta várias versões do Python. .FLAVORS será definido para as versões suportadas do Python. Veja para maiores informações. USE_PYTHON=optsuffix Se a versão atual do Python não for a versão padrão, o port receberá PKGNAMESUFFIX=${PYTHON_PKGNAMESUFFIX}. É útil apenas com flavors. PYTHON_PKGNAMEPREFIX Usado como um PKGNAMEPREFIX para distinguir pacotes para diferentes versões do Python. Exemplo: py27- PYTHON_SITELIBDIR Local da árvore site-packages, que contém o caminho de instalação do Python (geralmente LOCALBASE). A PYTHON_SITELIBDIR pode ser muito útil ao instalar módulos Python. PYTHONPREFIX_SITELIBDIR A variante PREFIX-clean do PYTHON_SITELIBDIR. Sempre use %%PYTHON_SITELIBDIR%% no pkg-plist quando possível. O valor padrão de %%PYTHON_SITELIBDIR%% é lib/python%%PYTHON_VERSION%%/site-packages PYTHON_CMD Linha de comando do interpretador Python, incluindo o número da versão.
Assistentes do Módulo de Dependências do Python PYNUMERIC Linha de dependência para extensão numérica. PYNUMPY Linha de dependência para a nova extensão numérica, numpy. (PYNUMERIC foi descontinuado pelo fornecedor upstream). PYXML Linha de dependência para a extensão XML (não é necessária para o Python 2.0 e superior, pois também está na distribuição base). PY_ENUM34 Dependência condicional do devel/py-enum34 dependendo da versão do Python. PY_ENUM_COMPAT Dependência condicional do devel/py-enum-compat dependendo da versão do Python. PY_PATHLIB Dependência condicional do devel/py-pathlib dependendo da versão do Python. PY_IPADDRESS Dependência condicional do net/py-ipaddress dependendo da versão do Python. PY_FUTURES Dependência condicional do devel/py-futures dependendo da versão do Python.
Uma lista completa das variáveis ​​disponíveis pode ser encontrada em /usr/ports/Mk/Uses/python.mk Todas as dependências para ports Python usando Python flavors (quer com USE_PYTHON=distutils ou USE_PYTHON=flavors) deve ter o flavor Python anexado à sua origem usando @${PY_FLAVOR}. Veja Makefile para um Módulo <application>Python</application> Simples. PORTNAME= sample DISTVERSION= 1.2.3 CATEGORIES= devel MAINTAINER= john@doe.tld COMMENT= Python sample module RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR} USES= python USE_PYTHON= autoplist distutils .include <bsd.port.mk> Algumas aplicações Python afirmam ter suporte a DESTDIR (que seria necessário para fazer o staging), mas ele está quebrado (Mailman até a versão 2.1.16, por exemplo). Isso pode ser contornado, recompilando os scripts. Isso pode ser feito, por exemplo, no target post-build. Assumindo que os scripts Python devem estar em PYTHONPREFIX_SITELIBDIR após a instalação, esta solução pode ser aplicada: (cd ${STAGEDIR}${PREFIX} \ && ${PYTHON_CMD} ${PYTHON_LIBDIR}/compileall.py \ -d ${PREFIX} -f ${PYTHONPREFIX_SITELIBDIR:S;${PREFIX}/;;}) Isso recompila os fontes com um caminho relativo ao diretório de stage e acrescenta o valor de PREFIX para o nome do arquivo gravado no arquivo bytecode de saída por -d. O -f é necessário para forçar a recompilação e o :S;${PREFIX}/;; remove prefixos do valor de PYTHONPREFIX_SITELIBDIR para torná-lo relativo ao PREFIX. Usando <application>Tcl/Tk</application> A Coleção de Ports suporta a instalação paralela de múltiplas versões do Tcl/Tk. Ports devem tentar suportar pelo menos a versão padrão do Tcl/Tk e superior com USES=tcl. É possível especificar a versão desejada do tcl anexando :xx, por exemplo, USES=tcl:85. As variáveis read only muito úteis para Ports que usam <application>Tcl/Tk</application> TCL_VER versão major.minor escolhida do Tcl TCLSH caminho completo do interpretador Tcl TCL_LIBDIR caminho das bibliotecas Tcl TCL_INCLUDEDIR caminho dos arquivos de cabeçalho C do Tcl TK_VER versão major.minor escolhida do Tk WISH caminho completo do interpretador Tk TK_LIBDIR caminho das bibliotecas Tk TK_INCLUDEDIR caminho dos arquivos de cabeçalho C do Tk
Veja o USES=tcl e USES=tk do para uma descrição completa dessas variáveis. Uma lista completa dessas variáveis ​​está disponível em /usr/ports/Mk/Uses/tcl.mk. Usando Ruby Variáveis ​​Úteis para Ports Que Usam Ruby Variável Descrição USE_RUBY Adiciona dependências de build e run no Ruby. USE_RUBY_EXTCONF O port utiliza extconf.rb para configurar. USE_RUBY_SETUP O port utiliza setup.rb para configurar. RUBY_SETUP Substitui o nome do script de configuração do setup.rb. Outro valor comum é install.rb.
Esta tabela mostra as variáveis ​​selecionadas disponíveis para os autores dos ports através da infraestrutura de ports. Essas variáveis ​​são usadas para instalar arquivos em seus locais apropriados. Use-os em pkg-plist tanto quanto possível. Não redefina essas variáveis no port. Variáveis ​​Somente Leitura Selecionadas para Ports Que Usam Ruby Variável Descrição Exemplo de valor RUBY_PKGNAMEPREFIX Usado como um PKGNAMEPREFIX para distinguir pacotes para diferentes versões do Ruby. ruby19- RUBY_VERSION Versão completa do Ruby na forma de x.y.z[.p]. 1.9.3.484 RUBY_SITELIBDIR Caminho de instalação de bibliotecas independentes de arquitetura. /usr/local/lib/ruby/site_ruby/1.9 RUBY_SITEARCHLIBDIR Caminho de instalação das bibliotecas dependentes de arquitetura. /usr/local/lib/ruby/site_ruby/1.9/amd64-freebsd10 RUBY_MODDOCDIR Caminho de instalação da documentação do módulo. /usr/local/share/doc/ruby19/patsy RUBY_MODEXAMPLESDIR Caminho de instalação dos exemplos do módulo. /usr/local/share/examples/ruby19/patsy
Uma lista completa das variáveis ​​disponíveis pode ser encontrada em /usr/ports/Mk/bsd.ruby.mk. Usando SDL O USE_SDL é usado para auto configurar as dependências para os ports que usam uma biblioteca baseada em SDL como o devel/sdl12 e o graphics/sdl_image. Estas bibliotecas SDL para a versão 1.2 são reconhecidas: sdl: devel/sdl12 console: devel/sdl_console gfx: graphics/sdl_gfx image: graphics/sdl_image mixer: audio/sdl_mixer mm: devel/sdlmm net: net/sdl_net pango: x11-toolkits/sdl_pango sound: audio/sdl_sound ttf: graphics/sdl_ttf Estas são as bibliotecas SDL para a versão 2.0 reconhecidas: sdl: devel/sdl20 gfx: graphics/sdl2_gfx image: graphics/sdl2_image mixer: audio/sdl2_mixer net: net/sdl2_net ttf: graphics/sdl2_ttf Portanto, se um port tiver uma dependência do net/sdl_net e do audio/sdl_mixer, a sintaxe será: USE_SDL= net mixer A dependência devel/sdl12, a qual é exigida por net/sdl_net e audio/sdl_mixer, é automaticamente adicionada também. Usar USE_SDL com entradas para o SDL 1.2, irá automaticamente: Adicionar uma dependência em sdl12-config para BUILD_DEPENDS Adicionar a variável SDL_CONFIG em CONFIGURE_ENV Adicionar as dependências das bibliotecas selecionadas ao LIB_DEPENDS Usar USE_SDL com entradas para o SDL 2.0, irá automaticamente: Adicionar uma dependência em sdl2-config para BUILD_DEPENDS Adicionar a variável SDL2_CONFIG ao CONFIGURE_ENV Adicionar as dependências das bibliotecas selecionadas ao LIB_DEPENDS Usando <application>wxWidgets</application> Esta seção descreve o status das bibliotecas wxWidgets na árvore de ports e sua integração com o sistema de ports. Introdução Existem muitas versões das bibliotecas do wxWidgets que entram em conflito entre elas (instalam arquivos com o mesmo nome). Na árvore de ports este problema foi resolvido instalando cada versão sob um nome diferente usando sufixos de número de versão. A desvantagem óbvia disso é que cada aplicativo precisa ser modificado para encontrar a versão esperada. Felizmente, a maioria dos aplicativos chama o script wx-config para determinar os sinalizadores necessários para o compilador e o vinculador. O script é nomeado de maneira diferente para cada versão disponível. A maioria dos aplicativos respeita uma variável de ambiente ou aceita um argumento de configuração para especificar o script wx-config que deve ser chamado. Caso contrário, eles têm que ser corrigidos. Seleção de Versão Para fazer o port usar uma versão específica do wxWidgets existem duas variáveis ​​disponíveis para definir (se apenas uma for definida, a outra será definida para um valor padrão): Variáveis ​​para Selecionar as Versões do <application>wxWidgets</application> Variável Descrição Valor padrão USE_WX Lista de versões que o port pode usar Todas as versões disponíveis USE_WX_NOT Lista de versões que o port não pode usar Nenhum
As versões disponíveis do wxWidgets e os ports correspondentes na árvore são: Versões Disponíveis do <application>wxWidgets</application> Versão Port 2.8 x11-toolkits/wxgtk28 3.0 x11-toolkits/wxgtk30
As variáveis ​​em podem ser definidas para uma ou mais dessas combinações separadas por espaços: Especificações de Versão do <application>wxWidgets</application> Descrição Exemplo Versão única 2.8 Range ascendente 2.8+ Range descendente 3.0- Range total (deve ser crescente) 2.8-3.0
Também existem algumas variáveis ​​para selecionar as versões preferidas entre as disponíveis. Elas podem ser configuradas para uma lista de versões, as primeiras terão maior prioridade. Variáveis ​​para selecionar as versões preferidas do <application>wxWidgets</application> Nome Desenhado para WANT_WX_VER o port WITH_WX_VER o usuário
Seleção de Componentes Existem outras aplicações que, apesar de não serem bibliotecas wxWidgets, estão relacionadas a eles. Estas aplicações podem ser especificadas em WX_COMPS. Estes componentes estão disponíveis: Componentes <application>wxWidgets</application> Disponíveis Nome Descrição Restrição de versão wx biblioteca principal nenhum contrib bibliotecas contribuídas none python wxPython(ligações Python) 2.8-3.0
O tipo de dependência pode ser selecionado para cada componente, adicionando-se um sufixo separado por um ponto-e-vírgula. Se não estiver presente, será usado um tipo padrão (veja ). Estes tipos estão disponíveis: Tipos de Dependências <application>wxWidgets</application> Disponíveis Nome Descrição build Componente é necessário para a compilação, equivalente a BUILD_DEPENDS run O componente é necessário para execução, equivalente a RUN_DEPENDS lib O componente é necessário para a compilação e execução, equivalente a LIB_DEPENDS
Os valores padrão para os componentes estão detalhados nesta tabela: Tipos de Dependência Padrão do <application>wxWidgets</application> Componente Tipo de dependência wx lib contrib lib python run mozilla lib svg lib
Selecionando Componentes <application>wxWidgets</application> Este fragmento corresponde a um port que usa wxWidgets versão 2.4 e suas bibliotecas contribuídas. USE_WX= 2.8 WX_COMPS= wx contrib Detectando Versões Instaladas Para detectar uma versão instalada, defina WANT_WX. Se não estiver definido para uma versão específica, os componentes terão um sufixo de versão. O HAVE_WX será preenchido após a detecção. Detectando as versões instaladas <application>wxWidgets</application> e seus componentes Este fragmento pode ser usado em um port que usa wxWidgets se estiver instalado ou uma opção estiver selecionada. WANT_WX= yes .include <bsd.port.pre.mk> .if defined(WITH_WX) || !empty(PORT_OPTIONS:MWX) || !empty(HAVE_WX:Mwx-2.8) USE_WX= 2.8 CONFIGURE_ARGS+= --enable-wx .endif Este fragmento pode ser usado em um port que permite suporte ao wxPython se ele estiver instalado ou se uma opção for selecionada, em adição ao wxWidgets, ambas nas versões 2.8. USE_WX= 2.8 WX_COMPS= wx WANT_WX= 2.8 .include <bsd.port.pre.mk> .if defined(WITH_WXPYTHON) || !empty(PORT_OPTIONS:MWXPYTHON) || !empty(HAVE_WX:Mpython) WX_COMPS+= python CONFIGURE_ARGS+= --enable-wxpython .endif Variáveis ​​Definidas Estas variáveis ​​estão disponíveis no port (depois de definir uma de ). Variáveis ​​definidas para ports que usam <application>wxWidgets</application> Nome Descrição WX_CONFIG O caminho para o script wxWidgets wx-config (com nome diferente) WXRC_CMD O caminho para o programa wxWidgets wxrc (com nome diferente) WX_VERSION A versão do wxWidgets que será usada (por exemplo,2.6)
Processando em <filename>bsd.port.pre.mk</filename> Defina WX_PREMK para ser capaz de usar as variáveis ​​logo após a inclusão do bsd.port.pre.mk. Ao definir WX_PREMK, a versão, dependências, componentes e variáveis ​​definidas não serão alteradas mesmo se alterado as variáveis ​​do port wxWidgets depois de incluir o bsd.port.pre.mk. Usando Variáveis ​​nos Comandos <application>wxWidgets</application> Este fragmento ilustra o uso de WX_PREMK executando o script wx-config para obter a string de versão completa, atribuí-lo a uma variável e passá-lo para o programa. USE_WX= 2.8 WX_PREMK= yes .include <bsd.port.pre.mk> .if exists(${WX_CONFIG}) VER_STR!= ${WX_CONFIG} --release PLIST_SUB+= VERSION="${VER_STR}" .endif As variaveis wxWidgets ​​podem ser usadas com segurança em comandos quando estão dentro de targets sem a necessidade de WX_PREMK. Argumentos Adicionais do <command>configure</command> Alguns scripts GNU configure não podem encontrar wxWidgets com apenas o conjunto de variáveis ​​de ambiente WX_CONFIG, exigindo argumentos adicionais. WX_CONF_ARGS pode ser usado para fornecê-los. Valores Legais para <varname>WX_CONF_ARGS</varname> Valor possível Argumento resultante absolute --with-wx-config=${WX_CONFIG} relative --with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}
Usando <application>Lua</application> Esta seção descreve o status das bibliotecas Lua na árvore de ports e sua integração com o sistema de ports. Introdução Existem muitas versões das bibliotecas Lua e interpretadores correspondentes, que entram em conflito entre eles (instalam arquivos com o mesmo nome). Na árvore de ports este problema foi resolvido instalando cada versão sob um nome diferente usando sufixos de número de versão. A desvantagem óbvia disso é que cada aplicativo precisa ser modificado para encontrar a versão esperada. Mas isto pode ser resolvido adicionando alguns sinalizadores adicionais ao compilador e ao linker. Seleção de Versão Um port usando Lua só precisa ter essa linha: USES= lua Se uma versão específica do Lua for necessária, as instruções sobre como selecioná-la são fornecidas no USES=lua parte do . Variáveis ​​Definidas Essas variáveis ​​estão disponíveis no port. Variáveis ​​Definidas para Ports Que Usam <application>Lua</application> Nome Descrição LUA_VER A versão Lua que será usada (por exemplo,5,1) LUA_VER_STR A versão Lua sem os pontos (por exemplo,51) LUA_PREFIX O prefixo onde o Lua (e os seus componentes) é instalado LUA_SUBDIR O diretório sob ${PREFIX}/bin, ${PREFIX}/share e ${PREFIX}/lib no qual o Lua é instalado LUA_INCDIR O diretório no qual o Lua e os arquivos de cabeçalho tolua são instalados LUA_LIBDIR O diretório no qual o Lua e as bibliotecas tolua são instalados LUA_MODLIBDIR O diretório no qual as bibliotecas dos módulos Lua (.so) são instalados LUA_MODSHAREDIR O diretório no qual os módulos Lua (.lua) são instalados LUA_PKGNAMEPREFIX O prefixo do nome do pacote usado por módulos Lua LUA_CMD O caminho para o interpretador Lua LUAC_CMD O caminho para o compilador Lua
Usando <command>iconv</command> Após 2013-10-08 (254273), o FreeBSD 10-CURRENT e as versões mais recentes têm um iconv nativo no sistema operacional. Em versões anteriores, o converters/libiconv era usado como dependência. Para softwares que precisam do iconv, defina USES=iconv. As versões do FreeBSD antes do 10-CURRENT em 2013-08-13 (254273) não tem um iconv nativo. Nestas versões anteriores, uma dependência do converters/libiconv será adicionada automaticamente. Quando um port define USES=iconv, estas variáveis ​​estarão disponíveis: Nome da variável Propósito Valor antes do FreeBSD 10-CURRENT 254273(2013-08-13) Valor após o FreeBSD 10-CURRENT 254273(2013-08-13) ICONV_CMD Diretório onde o binário iconv reside ${LOCALBASE}/bin/iconv /usr/bin/iconv ICONV_LIB argumento do ld para vincular ao libiconv (se necessário) -liconv (vazio) ICONV_PREFIX Diretório onde a implementação do iconv reside (útil para configurar scripts) ${LOCALBASE} /usr ICONV_CONFIGURE_ARG Argumento de configuração pré-configurado para scripts de configuração. --with-libiconv-prefix=${LOCALBASE} (vazio) ICONV_CONFIGURE_BASE Argumento de configuração pré-configurado para scripts de configuração. --with-libiconv=${LOCALBASE} (vazio) Esses dois exemplos preenchem automaticamente as variáveis ​​com o valor correto para sistemas usando respectivamente o converters/libiconv ou o iconv nativo: Simples uso do <command>iconv</command> USES= iconv LDFLAGS+= -L${LOCALBASE}/lib ${ICONV_LIB} Uso do <command>iconv</command> com <command>configure</command> USES= iconv CONFIGURE_ARGS+=${ICONV_CONFIGURE_ARG} Como mostrado acima, a variável ICONV_LIB estará vazia quando um iconv nativo estiver presente. Isso pode ser usado para detectar o iconv nativo e responder adequadamente. Às vezes um programa tem um argumento ld ou caminho de pesquisa codificado em um Makefile ou no script configure. Essa abordagem pode ser usada para resolver esse problema: Corrigindo Hardcoded <literal>-liconv</literal> USES= iconv post-patch: @${REINPLACE_CMD} -e 's/-liconv/${ICONV_LIB}/' ${WRKSRC}/Makefile Em alguns casos, é necessário definir valores alternativos ou executar operações dependendo se há um iconv nativo. O bsd.port.pre.mk deve ser incluído antes de testar o valor de ICONV_LIB: Verificando Disponibilidade do <command>iconv</command> Nativo USES= iconv .include <bsd.port.pre.mk> post-patch: .if empty(ICONV_LIB) # native iconv detected @${REINPLACE_CMD} -e 's|iconv||' ${WRKSRC}/Config.sh .endif .include <bsd.port.post.mk> Usando o Xfce Ports que precisam de bibliotecas ou aplicações Xfce, utilizam USES=xfce. Dependencias específicas de bibliotecas e aplicativos Xfce são definidas com valores atribuídos a USE_XFCE. Eles são definidos em /usr/ports/Mk/Uses/xfce.mk. Os valores possíveis são: Valores de <varname>USE_XFCE</varname> garcon sysutils/garcon libexo x11/libexo libgui x11-toolkits/libxfce4gui libmenu x11/libxfce4menu libutil x11/libxfce4util painel x11-wm/xfce4-panel thunar x11-fm/thunar xfconf x11/xfce4-conf Exemplo de <varname>USES=xfce</varname> USES= xfce USE_XFCE= libmenu Usando os Próprios Widgets GTK3 do Xfce Neste exemplo, o aplicativo portado usa os widgets específicos do GTK3, o x11/libxfce4menu e o x11/xfce4-conf. USES= xfce:gtk3 USE_XFCE= libmenu xfconf Os componentes Xfce incluídos dessa maneira incluirão automaticamente todas as dependências necessárias. Não é mais necessário especificar a lista inteira. Se o port precisar apenas de x11-wm/xfce4-panel, use: USES= xfce USE_XFCE= panel Não há necessidade de listar os componentes que o x11-wm/xfce4-panel precisa para ele mesmo, desta forma: USES= xfce USE_XFCE= libexo libmenu libutil panel Contudo, os componentes Xfce e as dependências do port que não dependem do Xfce devem ser incluídas explicitamente. Não conte com um componente Xfce para fornecer uma sub-dependência diferente de si para o port principal. Usando Bancos de Dados Utilize uma das macros USES de para adicionar a dependência de um banco de dados. Banco de Dados de Macros <varname>USES</varname> Base de Dados Macro USES Berkeley DB bdb MariaDB, MySQL, Percona mysql PostgreSQL pgsql SQLite sqlite
Usando o Berkeley DB 6 USES= bdb:6 Veja para maiores informações. Usando MySQL Quando um port precisa da biblioteca cliente do MySQL, adicione USES= mysql Veja para mais informações. Usando PostgreSQL Quando um port precisar do servidor PostgreSQL versão 9.6 ou posterior, adicione USES= pgsql:9.6+ WANT_PGSQL= server Veja para mais informações. Usando SQLite 3 USES= sqlite:3 Veja para mais informações. Iniciando e Parando Serviços (com scripts <literal>rc</literal>) Os scripts rc.d são usados ​​para iniciar serviços na inicialização do sistema e para fornecer aos administradores uma maneira padrão de parar, iniciar e reiniciar o serviço. Ports se integram ao sistema de estrutura do rc.d. Detalhes sobre seu uso podem ser encontrados no capitulo sobre rc.d do handbook. A explicação detalhada dos comandos disponíveis é fornecida em rc8 e rc.sub8. Finalmente, existe um artigo sobre aspectos práticos do sistema de scripts do rc.d. Com um port mítico chamadodoorman, o qual precisa iniciar um daemon doormand. Adicione o seguinte ao Makefile: USE_RC_SUBR= doormand Vários scripts podem ser listados e serão instalados. Os scripts devem ser colocados no subdiretório files e um sufixo .in deve ser adicionado ao nome do arquivo. Expansões padrões SUB_LIST serão executadas neste arquivo. Usar as expansões %%PREFIX%% e %%LOCALBASE%% também é fortemente encorajado. Veja mais sobre a SUB_LIST na seção relevante. A partir do FreeBSD 6.1-RELEASE, scripts locais rc.d (incluindo aqueles instalados pelos ports) estão incluídos no rcorder8 do sistema base. Um exemplo simples de script rc.d para iniciar o daemon doormand: #!/bin/sh # $FreeBSD$ # # PROVIDE: doormand # REQUIRE: LOGIN # KEYWORD: shutdown # # Add these lines to /etc/rc.conf.local or /etc/rc.conf # to enable this service: # # doormand_enable (bool): Set to NO by default. # Set it to YES to enable doormand. # doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf # by default. . /etc/rc.subr name=doormand rcvar=doormand_enable load_rc_config $name : ${doormand_enable:="NO"} : ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"} command=%%PREFIX%%/sbin/${name} pidfile=/var/run/${name}.pid command_args="-p $pidfile -f $doormand_config" run_rc_command "$1" A menos que haja uma boa razão para iniciar o serviço mais cedo, ou ele seja executado como um usuário específico (diferente de root), todos os scripts de ports devem usar: REQUIRE: LOGIN Se o script de inicialização iniciar um daemon que deve ser desligado, o seguinte acionará uma parada do serviço no desligamento do sistema: KEYWORD: shutdown Se o script não está iniciando um serviço persistente, isso não é necessário. Para os elementos de configuração opcional o estilo "=" de atribuição de variável padrão é preferível ao estilo ":=", já que o primeiro define um valor padrão apenas se a variável não estiver definida, e o segundo define um se a variável não está definida ou se ela é nula. Um usuário pode muito bem incluir algo como: doormand_flags="" no seu rc.conf.local, e uma substituição de variável usando ":=" substituirá inadequadamente a intenção do usuário. A variável _enable não é opcional e deve usar o ":" por padrão. Os Ports não devem iniciar e parar seus serviços durante a instalação e desinstalação. Não abuse das keywords plist descritas em executando comandos que modificam o sistema em execução, incluindo iniciar ou interromper serviços. Pre-Commit Checklist Antes de contribuir um port com um script rc.d, e mais importante, antes de realizar o commit de um, por favor consulte esta lista de verificação para ter certeza de que ele está pronto. O port devel/rclint pode verificar a maioria destes itens, mas não substitui uma revisão adequada. Se este é um novo arquivo, ele tem uma extensão .sh? Se assim for, isso deve ser mudado para apenas file.in uma vez que os arquivos rc.d não podem terminar com essa extensão. O arquivo tem uma tag $FreeBSD$? O nome do arquivo (menos .in), a linha PROVIDE e $name são as mesmas? O nome do arquivo ao corresponder com o PROVIDE irá facilitar a depuração, especialmente para problemas de rcorder8. Combinar o nome do arquivo e o $name torna mais fácil descobrir quais variáveis ​​são relevantes no rc.conf[.local]. Isso também é uma política para todos os novos scripts, incluindo aqueles no sistema base. A linha REQUIRE está definida para LOGIN? Isso é obrigatório para scripts que são executados como um usuário não root. Se ele for executado como root, há uma boa razão para ele ser executado antes de LOGIN? Caso contrário, ele deve ser executado depois para que os scripts locais possam ser agrupados em um ponto no rcorder8 depois que quase tudo no sistema base já estiver rodando. O script inicia um serviço persistente? Em caso afirmativo, ele deve ter o KEYWORD: shutdown. Certifique-se de que não há um KEYWORD: FreeBSD presente. Isto não foi necessário nem desejável durante anos. Isto também é uma indicação de que o novo script foi copiado/colado de um script antigo, portanto, um cuidado extra deve ser dado à revisão. Se o script usa uma linguagem interpretada como o perl, o python ou o ruby, certifique-se de que o command_interpreter está definido adequadamente, por exemplo, para o Perl, adicione PERL=${PERL} para a SUB_LIST e utilize %%PERL%%. De outra forma, # service name stop provavelmente não funcionará corretamente. Consulte service8 para maiores informações. Todas as ocorrências de /usr/local foram substituídas por %%PREFIX%%? As atribuições das variáveis ​​padrão vêm depois de load_rc_config? Existem atribuições padrões para sequências vazias? Elas devem ser removidas, mas verifique se a opção está documentada nos comentários na parte superior do arquivo. As variáveis ​​definidas estão realmente sendo utilizadas no script? As opções listadas no padrão name_flags são realmente obrigatórias? Se assim for, elas devem estar em command_args. A opção é uma flag vermelha (com o perdão do trocadilho) aqui, já que geralmente é a opção de "daemonizar" o processo e, portanto, é realmente obrigatório. O name_flags nunca deve ser incluído em command_args (e vice-versa, embora esse erro seja menos comum). O script executa qualquer código incondicionalmente? Isso é desaprovado. Normalmente, essas coisas devem ser tratadas através de um start_precmd. Todos os testes booleanos devem usar a função checkyesno. Nenhum teste deve usar [Yy][Ee][Ss], etc. Se houver um loop (por exemplo, esperando que algo inicie), ele tem um contador para terminar o loop? Não queremos que a inicialização seja bloqueada para sempre se houver um erro. O script cria arquivos ou diretórios que precisam de permissões específicas, por exemplo, um pid que precisa ser de propriedade do usuário que executa o processo? Em vez da rotina tradicional touch1/chown8/chmod1, considere usar install1 com os argumentos de linha de comando apropriados para fazer todo o procedimento com um passo. Adicionando Usuários e Grupos Alguns ports exigem que uma conta de usuário específica esteja presente, geralmente para daemons executados como esse usuário. Para esses ports, escolha um UID único entre 50 a 999 e registre-o em ports/UIDs (para usuários) e em ports/GIDs(para grupos). A identificação única deve ser a mesma para usuários e grupos. Por favor, inclua um patch para estes dois arquivos quando for necessário que um novo usuário ou grupo seja criado para o port. Então use USERS e GROUPS dentro do Makefile e o usuário será criado automaticamente ao instalar o port. USERS= pulse GROUPS= pulse pulse-access pulse-rt A lista atual de UIDs e GIDs reservados pode ser encontrada em ports/UIDs e ports/GIDs. Ports que Dependem dos Fontes do kernel Alguns ports (como módulos carregáveis ​​do kernel) precisam dos arquivos fonte do kernel para que o port possa ser compilado. Aqui está a maneira correta de determinar se o usuário os instalou: USES= kmod Além desta verificação, o recurso kmod cuida da maioria dos itens que esses ports precisam levar em consideração. Bibliotecas Go - Os ports não devem empacotar ou instalar bibliotecas Go ou código-fonte. Apenas lang/go* deve instalar em GO_SRCDIR e GO_LIBDIR. Os ports Go devem buscar as dependências na hora da compilação e devem instalar apenas programas que os usuários precisam, não o que os desenvolvedores Go precisam. + Os ports não devem empacotar ou instalar bibliotecas Go ou código-fonte. Os ports Go devem baixar as dependências na hora da compilação e devem instalar apenas programas que os usuários precisam, e não o que os desenvolvedores Go precisam. Ports devem (por ordem de preferência): Usar as dependências fornecidas no código fonte do pacote. - Buscar as versões das dependências especificadas pelo upstream (no caso do vendor.json ou similar). + Baixar as versões das dependências especificadas pelo upstream (no caso do go.mod, vendor.json ou similar). Como um último recurso (as dependências não estão incluídas e nem as versões foram especificadas exatamente) busque as versões das dependências disponíveis no momento do desenvolvimento/release. Arquivos Shell Completion Muitos shells modernos (incluindo bash, tcsh e zsh) suportam parâmetro e/ou opção de tab-completion. Esse suporte geralmente vem de arquivos completion, os quais contêm as definições de como as tabs completion funcionarão para um determinado comando. As vezes ports vem com seus arquivos completion, ou os mantenedores de ports podem ter criado um eles mesmos. Quando disponível, os arquivos de completion devem sempre ser instalados. Não é necessário fazer uma opção para eles. Apesar que se uma opção for usada, sempre habilite-a em OPTIONS_DEFAULT. Caminhos dos arquivos shell completion bash ${PREFIX}/etc/bash_completion.d zsh ${PREFIX}/share/zsh/site-functions
Não registre nenhuma dependência nos próprios shells. Flavors Uma Introdução aos Flavors Os flavors são uma maneira de ter várias variações de um port. O port é construído várias vezes, com variações. Por exemplo, um port pode ter uma versão normal com muitos recursos e algumas dependências, e uma versão leve lite com apenas recursos básicos e dependências mínimas. Outro exemplo poderia ser, um port pode ter um flavor GTK e um QT, dependendo de qual kit de ferramentas ele usa. Usando FLAVORS Para declarar um port com vários flavors, adicione FLAVORS no seu Makefile. O primeiro flavor em FLAVORS é o flavor padrão. Isso pode ajudar a simplificar a lógica do Makefile para também definir um FLAVOR como: FLAVOR?= ${FLAVORS:[1]} Para distinguir os flavors das opções, que são sempre letras maiúsculas, os nomes dos flavors podem conter apenas letras minúsculas, números e underline _. Uso Básico de Flavors Se um port tiver um port slave lite, o port slave pode ser removido, e o port pode ser convertido em flavors com: FLAVORS= default lite lite_PKGNAMESUFFIX= -lite [...] .if ${FLAVOR:U} != lite [enable non lite features] .endif O primeiro flavor é o padrão, e é chamado aqui de default. Não é uma obrigação e, se possível, use um nome de flavor mais específico, como em . Outro Uso Básico de Flavors Se um port tiver um port slave -nox11, o port slave pode ser removido, e o port pode ser convertido em flavors com: FLAVORS= x11 nox11 FLAVOR?= ${FLAVORS:[1]} nox11_PKGNAMESUFFIX= -nox11 [...] .if ${FLAVOR} == x11 [enable x11 features] .endif Uso Mais Complexo de Flavors Aqui está um excerto ligeiramente editado do que está presente em devel/libpeas, um port que usa os flavors Python. Com as versões padrões do Python 2 e 3 sendo 2.7 e 3.6, ele irá automaticamente mudar para FLAVORS=py27 py36 USES= gnome python USE_PYTHON= flavors .if ${FLAVOR:Upy27:Mpy2*} USE_GNOME= pygobject3 CONFIGURE_ARGS+= --enable-python2 --disable-python3 BUILD_WRKSRC= ${WRKSRC}/loaders/python INSTALL_WRKSRC= ${WRKSRC}/loaders/python .else # py3* USE_GNOME+= py3gobject3 CONFIGURE_ARGS+= --disable-python2 --enable-python3 \ ac_cv_path_PYTHON3_CONFIG=${LOCALBASE}/bin/python${PYTHON_VER}-config BUILD_WRKSRC= ${WRKSRC}/loaders/python3 INSTALL_WRKSRC= ${WRKSRC}/loaders/python3 .endif py34_PLIST= ${.CURDIR}/pkg-plist-py3 py35_PLIST= ${.CURDIR}/pkg-plist-py3 py36_PLIST= ${.CURDIR}/pkg-plist-py3 Este port não usa o USE_PYTHON=distutils mas precisa do flavor Python de qualquer maneira. Para proteger contra o FLAVOR estar vazio, o que causaria um erro no make1, use ${FLAVOR:U} em comparações de strings em vez de ${FLAVOR}. As ligações gobject3 doGnome Python têm dois nomes diferentes, um para Python2, pygobject3 e um para Python3, py3gobject3. O script configure tem que ser executado em ${WRKSRC}, mas estamos interessados ​​apenas em compilar e instalar as partes Python 2 ou Python 3 do software, então configure os diretórios base de compilação e instalação apropriadamente. Sugestão sobre o nome correto do caminho do script de configuração do Python 3. A lista de empacotamento é diferente quando compilada com Python 3. Como existem três possíveis versões do Python3 , defina PLIST para todos os três usando o helper. Flavors Helpers Para tornar o Makefile mais fácil de ser escrito, existem alguns flavors helpers. Esta lista de helpers definirá sua variável: flavor_PKGNAMEPREFIX flavor_PKGNAMESUFFIX flavor_PLIST flavor_DESCR Esta lista de helpers será anexada à sua variável: flavor_CONFLICTS flavor_CONFLICTS_BUILD flavor_CONFLICTS_INSTALL flavor_PKG_DEPENDS flavor_EXTRACT_DEPENDS flavor_PATCH_DEPENDS flavor_FETCH_DEPENDS flavor_BUILD_DEPENDS flavor_LIB_DEPENDS flavor_RUN_DEPENDS flavor_TEST_DEPENDS Flavor Específico <varname>PKGNAME</varname>. Como todos os pacotes devem ter um nome de pacote diferente, os flavors devem mudar os seus, usando flavor_PKGNAMEPREFIX e o flavor_PKGNAMESUFFIX torna isso fácil: FLAVORS= normal lite lite_PKGNAMESUFFIX= -lite <literal>USES=php</literal> e Flavors Ao usar o USES=php com um destes argumentos, phpize, ext, zend ou pecl, o port terá automaticamente o FLAVORS preenchido com a versão PHP que ele suporta. Todos os exemplos assumem que as versões PHP suportadas atualmente são 5.6, 7.0, 7.1 e 7.2. Extensão Simples <literal>USES=php</literal> Isso irá gerar o pacote para todas as versões suportadas: PORTNAME= some-ext PORTVERSION= 0.0.1 PKGNAMEPREFIX= ${PHP_PKGNAMEPREFIX} USES= php:ext Isto irá gerar pacotes para todas as versões suportadas, menos a 7.2: PORTNAME= some-ext PORTVERSION= 0.0.1 PKGNAMEPREFIX= ${PHP_PKGNAMEPREFIX} USES= php:ext IGNORE_WITH_PHP= 72 Flavors PHP com Aplicações PHP Aplicações PHP também podem ter flavors. Isso permite gerar pacotes para todas as versões do PHP, para que os usuários possam usá-los com qualquer versão que precisarem em seus servidores. Aplicações PHP que são acrescidas de flavors devem acrescentar PHP_PKGNAMESUFFIX aos nomes dos pacotes. Adicionando Flavors em uma Aplicação PHP Incluir o suporte de Flavors em uma aplicação PHP é simples: PKGNAMESUFFIX= ${PHP_PKGNAMESUFFIX} USES= php:flavors Ao adicionar uma dependência em um port com flavors PHP, use @${PHP_FLAVOR}. Nunca use FLAVOR diretamente. <literal>USES=python</literal> e Flavors Ao usar USES=python e USE_PYTHON=distutils, o port irá automaticamente preencher FLAVORS com a versão Python que suporta. Simples <literal>USES=python</literal> Supondo que as versões suportadas do Python são 2.7, 3.4, 3.5 e 3.6, e a versão padrão do Python 2 e 3 são 2.7 e 3.6, um port com: USES= python USE_PYTHON= distutils Receberá esses flavors: py27 e py36. USES= python USE_PYTHON= distutils allflavors Receberá esses flavors: py27, py34, py35 e py36. <literal>USES=python</literal> com Requisitos de Versão Supondo que as versões suportadas do Python são 2.7, 3.4, 3.5 e 3.6, e a versão padrão do Python 2 e 3 são 2.7 e 3.6, um port com: USES= python:-3.5 USE_PYTHON= distutils Vai ter esse flavor: py27. USES= python:-3.5 USE_PYTHON= distutils allflavors Receberá esses flavors: py27, py34 e py35. USES= python:3.4+ USE_PYTHON= distutils Vai ter esse flavor: py36. USES= python:3.4+ USE_PYTHON= distutils allflavors Receberá esses flavors: py34, py35 e py36. A variável PY_FLAVOR é disponibilizada para depender da versão correta dos módulos Python. Todas as dependências em ports Python com flavors devem usar PY_FLAVOR, e não FLAVOR diretamente. Para um port que não usa <literal>distutils</literal> Se a versão padrão do Python3 é 3.6, o seguinte irá definir a variável PY_FLAVOR para py36: RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}mutagen>0:audio/py-mutagen@${PY_FLAVOR} USES= python:3.5+ Práticas Avançadas de <filename>pkg-plist</filename> Alterando o <filename>pkg-plist</filename> Baseado em Variáveis Make Alguns ports, particularmente os p5- ports, precisam mudar seus pkg-plist dependendo de quais opções eles são configurados com (ou versão de perl, no caso de p5- ports). Para tornar isso fácil, todas as instâncias pkg-plist de %%OSREL%%, %%PERL_VER%% e %%PERL_VERSION%% serão substituídas apropriadamente. O valor de %%OSREL%% é a revisão numérica do sistema operacional (por exemplo,4.9). %%PERL_VERSION%% e %%PERL_VER%% é o número completo da versão perl (por exemplo,5.8.9). Muitos outros %%VARS%% relacionados aos arquivos de documentação do port são descritos na seção relevante. Para fazer outras substituições, defina PLIST_SUB com uma lista de pares VAR=VALOR e as instâncias de %%VAR%% serão substituídas por VALOR no pkg-plist. Por exemplo, se um port instalar muitos arquivos em um subdiretório específico da versão, use um placeholder para a versão de modo que o pkg-plist não precise ser gerado novamente toda vez que o port é atualizado. Por exemplo: OCTAVE_VERSION= ${PORTREVISION} PLIST_SUB= OCTAVE_VERSION=${OCTAVE_VERSION} no Makefile e use %%OCTAVE_VERSION%% onde quer que a versão apareça em pkg-plist. Quando o port é atualizado, não será necessário editar dezenas (ou em alguns casos, centenas) de linhas no pkg-plist. Se os arquivos são instalados condicionalmente pelas opções definidas no port, a maneira usual de lidar com isso é prefixando as linhas pkg-plist com %%OPT%% para linhas necessárias quando a opção está ativada ou %%NO_OPT%% quando a opção está desativada e adicionando OPTIONS_SUB=yes ao Makefile. Veja para mais informações. Por exemplo, se houver arquivos que são instalados apenas quando a opção X11 está ativada, e o Makefile tem: OPTIONS_DEFINE= X11 OPTIONS_SUB= yes No pkg-plist, insira %%X11%% no início das linhas que serão instaladas apenas quando a opção estiver habilitada, assim: %%X11%%bin/foo-gui Esta substituição será feita entre os targets pre-install e do-install, lendo a partir do PLIST e escrevendo em TMPPLIST (padrão:WRKDIR/.PLIST.mktmp). Então, se o port gera o PLIST na hora da compilação, faça isso em ou antes do pre-install. Além disso, se o port precisar editar o arquivo resultante, faça-o em post-install em um arquivo chamado TMPPLIST. Outra maneira de modificar a lista de empacotamento de um port é baseada na configuração das variáveisPLIST_FILES e PLIST_DIRS. O valor de cada variável é considerado como uma lista de nomes de caminho para gravar no TMPPLIST junto com conteúdo do PLIST. Enquanto os nomes listados no PLIST_FILES e PLIST_DIRS estão sujeitos a substituição do %%VAR%% conforme descrito acima, é melhor usar o ${VAR} diretamente. Exceto por isso, os nomes contidos no PLIST_FILES aparecerão inalterados na lista final de packing, enquanto o @dir será anexado aos nomes do PLIST_DIRS. Para fazer efeito, o PLIST_FILES e o PLIST_DIRS devem ser definidos antes que o TMPPLIST seja escrito, isto é, no pre-install ou antes. De vez em quando, usar OPTIONS_SUB não é o suficiente. Nesses casos, adicionar uma TAG para PLIST_SUB dentro do Makefile com um valor especial @comment, faz as ferramentas de pacote ignorar a linha. Por exemplo, se alguns arquivos são instalados apenas quando a opção X11 está habilitada e a arquitetura é i386: .include <bsd.port.pre.mk> .if ${PORT_OPTIONS:MX11} && ${ARCH} == "i386" PLIST_SUB+= X11I386="" .else PLIST_SUB+= X11I386="@comment " .endif Diretórios Vazios Limpando Diretórios Vazios Ao ser desinstalado, um port deve remover os diretórios vazios que ele criou. A maioria desses diretórios são removidos automaticamente pelo pkg8, mas para os diretórios criados fora do ${PREFIX}, ou diretórios vazios, mais alguns passos precisam ser feitos. Isso geralmente é realizando adicionando entradas @dir para esses diretórios.Os subdiretórios devem ser excluídos antes de excluir os diretórios pai. [...] @dir /var/games/oneko/saved-games @dir /var/games/oneko Criando Diretórios Vazios Os diretórios vazios criados durante a instalação do port precisam de atenção especial. Eles devem estar presentes quando o pacote é criado. Se eles não forem criados pelo código do port, crie-os no Makefile: post-install: ${MKDIR} ${STAGEDIR}${PREFIX}/some/directory Adicione o diretório ao pkg-plist como qualquer outro. Por exemplo: @dir some/directory Arquivos de Configuração Se o port instalar arquivos de configuração em PREFIX/etc (ou em outro lugar) não liste-os em pkg-plist. Isso fará com que pkg delete remova os arquivos que foram cuidadosamente editados pelo usuário, e uma reinstalação irá eliminá-los. Em vez disso, instale arquivos de exemplo com uma extensão filename.sample. A macro @sample automatiza isso, consulte para entender o que ela faz exatamente. Para cada arquivo de exemplo, adicione uma entrada no pkg-plist: @sample etc/orbit.conf.sample Se houver uma boa razão para não instalar um arquivo de configuração por padrão, liste apenas o nome do arquivo de exemplo em pkg-plist, sem o @sample seguido por um espaço e adicione uma mensagem ressaltando que o usuário deve copiar e editar o arquivo antes que o software seja executado. Quando um port instala sua configuração em um subdiretório de ${PREFIX}/etc, usar ETCDIR, cujo padrão é ${PREFIX}/etc/${PORTNAME}, pode ser substituído nos Makefile dos ports se houver uma convenção para o port usar algum outro diretório. A macro %%ETCDIR%% será usado em seu lugar em pkg-plist Os arquivos de configuração de exemplo devem sempre ter o sufixo .sample. Se, por algum motivo histórico, o uso do sufixo padrão não for possível ou se os arquivos de exemplo vierem de algum outro diretório, use esta construção: @sample etc/orbit.conf-dist etc/orbit.conf ou @sample %%EXAMPLESDIR%%/orbit.conf etc/orbit.conf O formato é @sample sample-file actual-config-file. Lista de Pacotes Estática versus Dinâmica Uma lista de pacotes estáticos é uma lista de pacotes que está disponível na Coleção de Ports ou como pkg-plist (com ou sem substituição de variável), ou embutido no Makefile através do PLIST_FILES e do PLIST_DIRS. Mesmo se o conteúdo for gerado automaticamente por uma ferramenta ou um taget no Makefile antes da inclusão na Coleção de Ports por um committer (por exemplo, usando make makeplist>), isso ainda é considerado uma lista estática, já que é possível examiná-la sem ter que baixar ou compilar o distfile. Uma lista de pacotes dinâmicos é uma lista de pacotes que é gerada no momento em que o port é compilado com base nos arquivos e diretórios que estão instalados. Não é possível examiná-lo antes que o código-fonte do aplicativo portado seja baixado e compilado, ou após executar um make clean. Embora o uso de listas de pacotes dinâmicos não seja proibido, os mantenedores devem usar listas de pacotes estáticos sempre que possível, já que isso permite aos usuários utilizar grep1 nos de ports disponíveis para descobrir, por exemplo, qual port instala um determinado arquivo. Listas dinâmicas devem ser usadas principalmente para ports complexos onde a lista de pacotes muda drasticamente com base nos recursos opcionais do port (e assim manter uma lista de pacotes estática é impraticável), ou ports que alteram a lista de pacotes com base na versão do software dependente usado. Por exemplo, ports que geram documentos com Javadoc. Criação Automatizada da Lista de Pacotes Primeiro, verifique se o port está quase completo, faltando apenas o pkg-plist. Executar o comando make makeplist irá mostrar um exemplo para o pkg-plist. A saída do makeplist deve ser checada duas vezes quanto à correção, pois ela tenta adivinhar automaticamente algumas coisas e pode errar. Os arquivos de configuração do usuário devem ser instalados como filename.sample, como é descrito em . O info/dir não deve ser listado e entradas apropriadas install-info devem ser adicionadas conforme a seção arquivos de informação. Quaisquer bibliotecas instaladas pelo port devem ser listadas conforme especificado na seção bibliotecas compartilhadas. Expansão do <varname>PLIST_SUB</varname> com Expressões Regulares As strings a serem substituídas às vezes precisam ser muito específicas para evitar substituições indesejadas. Esse é um problema comum com valores mais curtos. Para resolver este problema, para cada PLACEHOLDER=value, um PLACEHOLDER_regex =regex pode ser definido, com o regex do value correspondendo mais precisamente. Usando PLIST_SUB com Expressões Regulares Os ports Perl podem instalar arquivos dependentes da arquitetura em uma árvore específica. No FreeBSD para facilitar a portabilidade, esta árvore é chamada de mach. Por exemplo, um port que instala um arquivo cujo caminho contém mach poderia ter essa parte da sequência do caminho substituída pelos valores incorretos. Considere este Makefile: PORTNAME= Machine-Build DISTVERSION= 1 CATEGORIES= devel perl5 MASTER_SITES= CPAN PKGNAMEPREFIX= p5- MAINTAINER= perl@FreeBSD.org COMMENT= Building machine USES= perl5 USE_PERL5= configure PLIST_SUB= PERL_ARCH=mach Os arquivos instalados pelo port são: /usr/local/bin/machine-build /usr/local/lib/perl5/site_perl/man/man1/machine-build.1.gz /usr/local/lib/perl5/site_perl/man/man3/Machine::Build.3.gz /usr/local/lib/perl5/site_perl/Machine/Build.pm /usr/local/lib/perl5/site_perl/mach/5.20/Machine/Build/Build.so Executar o make makeplist gera incorretamente: bin/%%PERL_ARCH%%ine-build %%PERL5_MAN1%%/%%PERL_ARCH%%ine-build.1.gz %%PERL5_MAN3%%/Machine::Build.3.gz %%SITE_PERL%%/Machine/Build.pm %%SITE_PERL%%/%%PERL_ARCH%%/%%PERL_VER%%/Machine/Build/Build.so Altere a linha PLIST_SUB do Makefile para: PLIST_SUB= PERL_ARCH=mach \ PERL_ARCH_regex=\bmach\b Agora o make makeplist gera corretamente: bin/machine-build %%PERL5_MAN1%%/machine-build.1.gz %%PERL5_MAN3%%/Machine::Build.3.gz %%SITE_PERL%%/Machine/Build.pm %%SITE_PERL%%/%%PERL_ARCH%%/%%PERL_VER%%/Machine/Build/Build.so Expandindo a Lista de Pacotes com Keywords Todas as keywords também podem ter argumentos opcionais entre parênteses. Os argumentos são owner, group e mode. Esse argumento é usado no arquivo ou diretório referenciado. Para alterar o dono, o grupo e o modo de um arquivo de configuração, use: @sample(games,games,640) etc/config.sample Os argumentos são opcionais. Se apenas o grupo e o modo precisarem ser alterados, use: @sample(,games,660) etc/config.sample Se uma keyword for utilizada em uma entrada de opção, ela precisa ser adicionada após o assistente: %%FOO%%@sample etc/orbit.conf.sample Isso é porque os assistentes plist das opções são utilizados para comentar as linhas, e por isso eles precisam ser inseridos no início. Veja para maiores informações. <literal>@desktop-file-utils</literal> Irá executar o update-desktop-database -q após a instalação e desinstalação. Nunca use diretamente, adicione USES=utilitários de arquivo de desktop ao Makefile. <literal>@fc</literal> <replaceable>directory</replaceable> Adiciona uma entrada @dir para o diretório passado como um argumento, e executa fc-cache -fs nesse diretório após a instalação e desinstalação. <literal>@fcfontsdir</literal> <replaceable>directory</replaceable> Adiciona uma entrada @dir para o diretório passado como um argumento, e executa fc-cache -fs, mkfontscale e mkfontdir nesse diretório após a instalação e desinstalação. Além disso, na desinstalação, ele remove os arquivos de cache fonts.scale e fonts.dir, se estiverem vazios. Esta keyword é equivalente a adicionar o diretório @fc e o diretório @fontsdir. <literal>@fontsdir</literal> <replaceable>directory</replaceable> Adiciona um entrada @dir para o diretório passado como um argumento, e executa mkfontscale e mkfontdir nesse diretório após a instalação e desinstalação. Além disso, na desinstalação, ele remove os arquivos de cache fonts.scale e fonts.dir, se estiverem vazios. <literal>@glib-schemas</literal> Executa glib-compile-schemas na instalação e desinstalação. <literal>@info</literal> <replaceable>file</replaceable> Adiciona o arquivo passado como argumento ao plist e atualiza o índice do documento info na instalação e desinstalação. Além disso, ele remove o índice se estiver vazio na desinstalação. Isso nunca deve ser usado manualmente, mas sempre INFO. Veja para maiores informações. <literal>@kld</literal> <replaceable>directory</replaceable> Executa o kldxref no diretório na instalação e desinstalação. Além disso, na desinstalação, ele removerá o diretório se estiver vazio. <literal>@rmtry</literal> <replaceable>file</replaceable> O arquivo será removido na desinstalação, e não dará um erro se o arquivo não estiver lá. <literal>@sample</literal> <replaceable>file</replaceable>[<replaceable>file</replaceable>] Isso é usado para lidar com a instalação de arquivos de configuração, através de arquivos de exemplo empacotados com o pacote. O arquivo atual, não-amostra, ou é o segundo nome do arquivo, se presente, ou o primeiro nome de arquivo sem a extensão .sample. Isso faz três coisas. Primeiro, adiciona o primeiro arquivo passado como argumento, o arquivo de exemplo, ao plist. Então, na instalação, se o arquivo real não for encontrado, copia o arquivo de exemplo para o arquivo real. E, finalmente, na desinstalação, remove o arquivo atual se ele não tiver sido modificado. Veja para maiores informações. <literal>@shared-mime-info</literal> <replaceable>directory</replaceable> Executa update-mime-database no diretório na instalação e desinstalação. <literal>@shell</literal> <replaceable>file</replaceable> Adiciona o arquivo passado como argumento ao plist. Na instalação, adiciona o caminho completo do file em /etc/shells, certificando-se que não é adicionado duas vezes. Na desinstalação, remove-o de /etc/shells. <literal>@terminfo</literal> Não use sozinho. Se o port for instalar arquivos *.terminfo, adicione USES=terminfo no seu Makefile. Na instalação e desinstalação, se o tic estiver presente, atualize o ${PREFIX}/share/misc/terminfo.db a partir dos arquivos *.terminfo disponíveis em ${PREFIX}/share/misc Keywords Básicas Existem algumas keywords que são codificadas e documentadas em pkg-create8. Por uma questão de completude, elas também estão documentadas aqui. <literal>@</literal> [<replaceable>file</replaceable>] A keyword vazia é um espaço reservado para ser usado quando o proprietário, grupo ou modo do arquivo precisam ser alterados. Por exemplo, para definir o grupo de um arquivo como games e adicionar o bit setgid, adicione: @(,games,2755) sbin/daemon <literal>@preexec</literal> <replaceable>command</replaceable>, <literal>@postexec</literal> <replaceable>command</replaceable>, <literal>@preunexec</literal> <replaceable>command</replaceable>, <literal>@postunexec</literal> <replaceable>command</replaceable> Executa o command como parte do processo de instalação ou desinstalação. @preexec command Executar o command como parte dos scripts pre-install. @postexec command Executar o command como parte dos scripts post-install. @preunexec command Executar o command como parte dos scripts pre-deinstall. @postunexec command Executar o command como parte dos scripts post-deinstall. E se o command contém qualquer uma dessas sequências em algum lugar, elas são expandidas em linha. Para estes exemplos, assuma que @cwd está configurado para /usr/local e o último arquivo extraído foi bin/emacs. %F Expandir para o último nome de arquivo extraído (conforme especificado). No caso do exemplo bin/emacs. %D Expandir para o prefixo do diretório atual, como definido no @cwd. No caso do exemplo /usr/local. %B Expandir para o nome de base do nome completo do arquivo, ou seja, o prefixo do diretório atual mais o último arquivo, menos o nome do arquivo final. No exemplo, isso seria /usr/local/bin. %f Expandir para a parte do nome do arquivo do nome totalmente qualificado, ou o inverso de %B. No caso do exemplo, emacs. Essas keywords estão aqui para ajudá-lo a configurar o pacote para que ele esteja tão pronto quanto possível. Elas não devem ser abusadas para iniciar serviços, interromper serviços ou executar quaisquer outros comandos que modificarão o sistema em execução. <literal>@mode</literal> <replaceable>mode</replaceable> Define a permissão padrão para todos os arquivos extraídos posteriormente para mode. O formato é o mesmo usado por chmod1. Use sem um argumento para voltar às permissões padrão (modo do arquivo enquanto estava sendo empacotado). Este deve ser um modo numérico, como 644, 4755 ou 600. Não pode ser um modo relativo comou+s. <literal>@owner</literal> <replaceable>user</replaceable> Define a propriedade padrão para todos os arquivos subsequentes para user. Use sem um argumento para voltar à propriedade padrão (root). <literal>@group</literal> <replaceable>group</replaceable> Define a propriedade de grupo padrão para todos os arquivos subsequentes para group. Use sem um argumento para retornar à propriedade do grupo padrão (wheel). <literal>@comment</literal> <replaceable>string</replaceable> Esta linha é ignorada no momento de empacotar. <literal>@dir</literal> <replaceable>directory</replaceable> Declara o nome do diretório. Por padrão, os diretórios criados sob PREFIX por uma instalação de pacote são automaticamente removidos. Use isto quando um diretório vazio sob PREFIX precisa ser criado ou quando o diretório precisa ter proprietário, grupo ou modo não padrão. Diretórios fora de PREFIX precisam ser registrados. Por exemplo, /var/db/${PORTNAME} precisa ter uma entrada @dir enquanto ${PREFIX}/share/${PORTNAME} não, se contiver arquivos ou usar o proprietário, grupo e modo padrão. <literal>@exec</literal> <replaceable>command</replaceable>, <literal>@unexec</literal> <replaceable>command</replaceable> (Descontinuado) Executa o command como parte do processo de instalação ou desinstalação. Por favor, use no lugar. <literal>@dirrm</literal> <replaceable>directory</replaceable> (Descontinuado) Declara o nome do diretório a ser excluído na desinstalação. Por padrão, os diretórios criados sob PREFIX por uma instalação de pacote são excluídos quando o pacote é desinstalado. <literal>@dirrmtry</literal> <replaceable>directory</replaceable> (Descontinuado) Declara o nome do diretório a ser removido, como para a keyword @dirrm, mas não emite um aviso se o diretório não puder ser removido. Criando Novas Keywords Os arquivos da lista de pacotes podem ser estendidos por keywords definidas no diretório ${PORTSDIR}/Keywords. As configurações de cada keyword são armazenadas em um arquivo UCL chamado keyword.ucl. O arquivo deve conter pelo menos uma destas seções: attributes action pre-install post-install pre-deinstall post-deinstall pre-upgrade post-upgrade <literal>attributes</literal> Altera o dono, grupo ou modo usado pela keyword. Contém uma matriz associativa em que as chaves possíveis são owner, group e mode. Os valores são, respectivamente, um nome de usuário, um nome de grupo e um modo de arquivo. Por exemplo: attributes: { owner: "games", group: "games", mode: 0555 } <literal>action</literal> Define o que acontece com o parâmetro da keyword. Contém uma matriz onde os valores possíveis são: setprefix Define o prefixo para as próximas entradas do plist. dir Registra um diretório para ser criado na instalação e removido na desinstalação. dirrm Registra um diretório a ser excluído na desinstalação. Descontinuado. dirrmtry Registra um diretório para tentar deletar na desinstalação. Descontinuado. file Registra um arquivo. setmode Define o modo para as próximas entradas do plist. setowner Define o dono para as próximas entradas do plist. setgroup Define o grupo para as próximas entradas do plist. comment Não faz nada, é o equivalente a não entrar em uma seção action. ignore_next Ignora a próxima entrada no plist. <literal>arguments</literal> Se definido para true, adiciona manipulação de argumentos, dividindo toda a linha, %@, em argumentos numerados,%1, %2, e assim por diante. Por exemplo, para esta linha: @foo some.content other.content %1 e %2 irão conter: some.content other.content Também afeta como a entrada action funciona. Quando há mais de um argumento, o número do argumento deve ser especificado. Por exemplo: actions: [file(1)] <literal>pre-install</literal>, <literal>post-install</literal>, <literal>pre-deinstall</literal>, <literal>post-deinstall</literal>, <literal>pre-upgrade</literal>, <literal>post-upgrade</literal> Essas keywords contêm um script sh1 a ser executado antes ou depois da instalação, desinstalação, ou atualização do pacote. Além do habitual placeholder @exec%foo descrito em , há um novo %@, que representa o argumento da keyword. Exemplos de Keywords Customizadas Exemplo de uma Keyword <literal>@dirrmtryecho</literal> Esta keyword faz duas coisas, adiciona uma linha @dirrmtry directory na lista de empacotamento, e escreve no log quando o diretório é removido ao desinstalar o pacote. actions: [dirrmtry] post-deinstall: <<EOD echo "Directory %D/%@ removed." EOD Exemplo na vida real, como o <literal>@sample</literal> é implementado Esta keyword faz três coisas. Ela adiciona o primeiro filename passado como um argumento para @sample na lista de empacotamento, ele adiciona instruções ao script de post-install para copiar o exemplo para o arquivo de configuração real, se ele ainda não existir, e adiciona instruções ao script post-deinstall para remover o arquivo de configuração se ele não tiver sido modificado. actions: [file(1)] arguments: true post-install: <<EOD case "%1" in /*) sample_file="%1" ;; *) sample_file="%D/%1" ;; esac target_file="${sample_file%.sample}" set -- %@ if [ $# -eq 2 ]; then target_file=${2} fi case "${target_file}" in /*) target_file="${target_file}" ;; *) target_file="%D/${target_file}" ;; esac if ! [ -f "${target_file}" ]; then /bin/cp -p "${sample_file}" "${target_file}" && \ /bin/chmod u+w "${target_file}" fi EOD pre-deinstall: <<EOD case "%1" in /*) sample_file="%1" ;; *) sample_file="%D/%1" ;; esac target_file="${sample_file%.sample}" set -- %@ if [ $# -eq 2 ]; then set -- %@ target_file=${2} fi case "${target_file}" in /*) target_file="${target_file}" ;; *) target_file="%D/${target_file}" ;; esac if cmp -s "${target_file}" "${sample_file}"; then rm -f "${target_file}" else echo "You may need to manually remove ${target_file} if it is no longer needed." fi EOD <filename>pkg-*</filename> Existem alguns truques que ainda não foram mencionamos sobre os arquivos pkg-* que são úteis às vezes. <filename>pkg-message</filename> - Para exibir uma mensagem quando o pacote é instalado, coloque a mensagem em pkg-message. Esse recurso é geralmente útil para exibir etapas adicionais de instalação a serem executadas após o pkg-install ou para exibir informações de licenciamento. + Para exibir uma mensagem quando o pacote é instalado, coloque a mensagem no pkg-message. Esse recurso é geralmente útil para exibir etapas adicionais de instalação a serem executadas após o pkg install ou pkg upgrade. - Quando algumas linhas sobre os knobs ou avisos de tempo de compilação tiverem que ser exibidos, use ECHO_MSG. O pkg-message é apenas para etapas de pós-instalação. Da mesma forma, a distinção entre ECHO_MSG é que ele serve para imprimir texto informativo na tela e o ECHO_CMD é serve para fazer pipelining de comandos: + + pkg-message deve conter apenas informações vitais de setup e operação no FreeBSD, e isso é único para o port em questão. - update-etc-shells: - @${ECHO_MSG} "updating /etc/shells" - @${CP} /etc/shells /etc/shells.bak - @( ${GREP} -v ${PREFIX}/bin/bash /etc/shells.bak; \ - ${ECHO_CMD} ${PREFIX}/bin/bash) >/etc/shells - @${RM} /etc/shells.bak + As informações de configuração devem ser mostradas apenas na instalação inicial. As instruções de atualização devem ser exibidas apenas ao atualizar a versão relevante. + Os committers têm aprovação implícita para restringir as mensagens existentes na hora da instalação ou em intervalos de atualização, usando as especificações do formato UCL. + + + pkg-message suporta dois formatos: + + + + raw + + + Um arquivo de texto simples. Sua mensagem é sempre exibida, na instalação e na atualização. + + + + + UCL + + + Se o arquivo começar com [ será considerado como um arquivo UCL. O formato UCL é descrito na página libucl no GitHub. + + + + Não adicione uma entrada para o pkg-message ao pkg-plist. + + + <acronym>UCL</acronym> no <filename>pkg-message</filename> + + O formato é o seguinte. Deve ser uma matriz de objetos. Os objetos em si podem ter essas palavras-chave: + + + + message + + + A mensagem atual a ser exibida. Esta palavra-chave é obrigatória. + + + + + type + + + Quando a mensagem deve ser exibida. + + + + + maximum_version + + + Somente se type for upgrade. Exibe se estiver atualizando de uma versão inferior que a versão especificada. + + + + + minimum_version + + + Somente se type for upgrade. Exibe se estiver atualizando de uma versão maior que a versão especificada. + + + + + As palavras-chave maximum_version e minimum_version podem ser combinadas. + + A palavra-chave type pode ter quatro valores: + + + + (nenhum tipo especificado) + + + A mensagem é sempre exibida. + + + + + install + + + A mensagem só deve ser exibida quando o pacote é instalado. + + + + + remove + + + A mensagem só deve ser exibida quando o pacote é removido. + + + + + upgrade + + + a mensagem só deve ser exibida durante uma atualização do pacote. + + + + + + O UCL permite dois tipos de strings, as delimitadas por aspas duplas "foo", e as strings com o formato <<EOM. Estes dois são equivalentes: + + [ +{ message: "Always displayed" +} +] + + [ +{ message: <<EOM +Always displayed +EOM +} +] + + + + Para preservar a compatibilidade com arquivos pkg-message não UCL, a primeira linha de um arquivo pkg-message UCL DEVE ter um simples [, e a última linha DEVE ter um simples ]. + + + + Sempre Exibir uma Mensagem + + Se um port tiver um pkg-message contendo texto simples, ele pode ser transformado em UCL facilmente. Veja este pkg-message: + + * BIND requires configuration of rndc, including a "secret" key. * +* The easiest, and most secure way to configure rndc is to run * +* 'rndc-confgen -a' to generate the proper conf file, with a new * +* random key, and appropriate file permissions. * + + [ +{ + message: <<EOD +* BIND requires configuration of rndc, including a "secret" key. * +* The easiest, and most secure way to configure rndc is to run * +* 'rndc-confgen -a' to generate the proper conf file, with a new * +* random key, and appropriate file permissions. * +EOD +} +] + + + + Exibir uma Mensagem na Instalação/Desinstalação + + Quando uma mensagem precisa ser exibida apenas na instalação ou na desinstalação, defina o tipo: + + [ +{ + message: "package being removed." + type: remove +} +{ message: "package being installed.", type: install } +] + + + + Exibir uma Mensagem na Atualização + + Quando um port é atualizado, a mensagem exibida pode ser ainda mais adaptada às necessidades do port. + + [ +{ + message: "Package is being upgraded." + type: upgrade +} +{ + message: "Upgrading from before 1.0 need to do this." + maximum_version: "1.0" + type: upgrade +} +{ + message: "Upgrading from after 1.0 should do that." + minimum_version: "1.0" + type: upgrade +} +{ + message: "Upgrading from > 1.0 and < 3.0 remove that file." + maximum_version: "3.0" + minimum_version: "1.0" + type: upgrade +} +] + + <filename>pkg-install</filename> Se o port precisa executar comandos quando o pacote binário é instalado com o pkg add ou com o pkg install, use o pkg-install. Este script será automaticamente adicionado ao pacote. Será executado duas vezes pelo pkg, a primeira vez como ${SH} pkg-install ${PKGNAME} PRE-INSTALL antes que o pacote seja instalado e uma segunda vez como ${SH} pkg-install ${PKGNAME} POST-INSTALL depois dele ter sido instalado. O valor de $2 pode ser testado para determinar em que modo o script está sendo executado. A variável de ambiente PKG_PREFIX será definida para o diretório de instalação do pacote. Este script está aqui para ajudá-lo a configurar o pacote para que ele esteja tão pronto quanto possível para ser usado. Ele não deve ser abusado para iniciar serviços, interromper serviços ou executar quaisquer outros comandos que modificarão o sistema em execução no momento. <filename>pkg-deinstall</filename> Este script é executado quando um pacote é removido. Este script será executado duas vezes pelo pkg delete. A primeira vez como ${SH} pkg-deinstall ${PKGNAME} DEINSTALL antes que o port seja desinstalado e a segunda vez como ${SH} pkg-deinstall ${PKGNAME} POST-DEINSTALL após o port ter sido desinstalado. O valor de $2 pode ser testado para determinar em que modo o script está sendo executado. A variável de ambiente PKG_PREFIX será definida para o diretório de instalação do pacote. Este script está aqui para ajudá-lo a configurar o pacote para que ele esteja tão pronto quanto possível para ser usado. Ele não deve ser abusado para iniciar serviços, interromper serviços ou executar quaisquer outros comandos que modificarão o sistema em execução no momento. Mudando os nomes dos <filename>pkg-<replaceable>*</replaceable></filename> Todos os nomes de pkg-* são definidos usando variáveis ​​que podem ser alteradas no Makefile se necessário. Isso é especialmente útil ao compartilhar os mesmos arquivos pkg-* entre vários ports ou quando é necessário gravar em um desses arquivos. Veja escrevendo em lugares que não o WRKDIR para entender por que é uma má ideia escrever diretamente no diretório que contém os arquivos pkg-*. Aqui está uma lista de nomes de variáveis ​​e seus valores padrão. (O valor padrão do PKGDIR é ${MASTERDIR}). Variável Valor padrão DESCR ${PKGDIR}/pkg-descr PLIST ${PKGDIR}/pkg-plist PKGINSTALL ${PKGDIR}/pkg-install PKGDEINSTALL ${PKGDIR}/pkg-deinstall PKGMESSAGE ${PKGDIR}/pkg-message Fazendo uso de <varname>SUB_FILES</varname> e <varname>SUB_LIST</varname> O SUB_FILES e o SUB_LIST são úteis para valores dinâmicos em arquivos do port, como o PREFIX de instalação dentro do pkg-message. A SUB_FILES especifica uma lista de arquivos a serem modificados automaticamente. Cada arquivo na lista SUB_FILES deve ter um arquivo.in correspondente presente no FILESDIR. Uma versão modificada será criada como ${WRKDIR}/arquivo. Os arquivos definidos como um valor de USE_RC_SUBR são automaticamente adicionados ao SUB_FILES. Para os arquivospkg-message, pkg-install e pkg-deinstall, a variável Makefile correspondente é automaticamente definida para apontar para a versão processada. A SUB_LIST é uma lista de pares VAR=VALUE. Para cada par, %%VAR%% será substituído por VALUE em cada arquivo listado em SUB_FILES. Vários pares comuns são definidos automaticamente: PREFIX, LOCALBASE, DATADIR, DOCSDIR, EXEMPLESDIR, WWWDIR e ETCDIR. Qualquer linha que comece com @Comment seguido por um espaço, será excluído dos arquivos resultantes após uma substituição de variável. Este exemplo substitui %%ARCH%% com a arquitetura do sistema em um pkg-message: SUB_FILES= pkg-message SUB_LIST= ARCH=${ARCH} Note que para este exemplo, o pkg-message.in deve existir no FILESDIR. Exemplo de um bom pkg-message.in: Now it is time to configure this package. Copy %%PREFIX%%/share/examples/putsy/%%ARCH%%.conf into your home directory as .putsy.conf and edit it. Testando o Port Executando <command>make describe</command> Várias das ferramentas de manutenção de ports do FreeBSD, tal como o portupgrade1, conta com um banco de dados chamado /usr/ports/INDEX o qual mantém um registro de itens tais como as dependências do port. O INDEX é criado pelo ports/Makefile de nível superior através do comando make index, que desce em cada subdiretório dos ports e executa o comando make describe lá. Desta forma, se o make describe falhar em qualquer port, ninguém poderá gerar o INDEX e muitas pessoas rapidamente se tornarão infelizes. É importante poder gerar este arquivo independentemente das opções presentes no make.conf então evite fazer coisas como usar declarações .error quando (por exemplo) uma dependência não estiver satisfeita. (Veja . E se o make describe produzir uma string em vez de uma mensagem de erro, provavelmente está tudo certo. Veja o bsd.port.mk para saber o significado da string gerada. Note também que rodar uma versão recente do portlint (conforme especificado na próxima seção) executará o make describe automaticamente. Portlint Verifique o port com portlint antes de submete-lo ou de fazer o seu commit. O portlint alerta sobre muitos erros comuns, tanto funcionais quanto de estilo. Para um novo (ou um repocopiado) port , portlint -A é o uso mais completo; para um port existente, portlint -C é suficiente. O portlint usa uma técnica heurística para tentar descobrir erros, pode produzir avisos falso-positivos. Além disso, ocasionalmente, algo que é sinalizado como um problema, pode não ter uma outra forma de ser realizado por limitações no framework dos ports. Em caso de dúvida, a melhor coisa a fazer é perguntar na Lista de discussão de ports do FreeBSD. Ferramentas do Ports O programa ports-mgmt/porttools faz parte da Coleção de Ports. O port é o script front-end, que pode ajudar a simplificar o trabalho de teste. Sempre que um novo port ou uma atualização de um já existente precisar de teste, use port test para testar o port, incluindo a verificação portlint. Este comando também detecta e lista todos os arquivos que não estão listados no pkg-plist. Por exemplo: # port test /usr/ports/net/csup <varname>PREFIX</varname> e <varname>DESTDIR</varname> PREFIX determina onde o port será instalado. O padrão é /usr/local, mas pode ser definido pelo usuário para um caminho personalizado como /opt. O port deve respeitar o valor dessa variável. O DESTDIR, se definido pelo usuário, determina o ambiente alternativo completo, geralmente uma jail ou um sistema instalado montado em outro local que não seja o /. Um port será realmente instalado no DESTDIR/PREFIX, e registrado no banco de dados de pacotes em DESTDIR/var/db/pkg. Como o DESTDIR é tratado automaticamente pela infraestrutura de ports com o chroot8. Não há necessidade de modificações ou qualquer cuidado extra para escrever ports compatíveis com o DESTDIR. O valor de PREFIX será definido para LOCALBASE (o valor padrão é /usr/local). E se USE_LINUX_PREFIX estiver definido o PREFIX será LINUXBASE (o valor padrão é /compat/linux). Evitar o uso do caminho /usr/local codificado no fonte tornam o port muito mais flexível e capaz de atender às necessidades de outros sites. Muitas vezes, isso pode ser feito substituindo as ocorrências de /usr/local nos vários Makefiles dos ports por ${PREFIX}. Essa variável é transmitida automaticamente para todos os estágios dos processos de compilação e instalação. Verifique se o aplicativo não está instalando arquivos em /usr/local ao invés de PREFIX. Um teste rápido para esses caminhos codificados é: % make clean; make package PREFIX=/var/tmp/`make -V PORTNAME` Se alguma coisa for instalada fora do PREFIX, o processo de criação de pacotes irá reclamar que não pode encontrar os arquivos. Além disso, vale a pena verificar o mesmo em relação ao suporte a diretórios stage (veja ): % make stage && make check-plist && make stage-qa && make package O check-plist verifica arquivos ausentes do plist e arquivos no plist que não são instalados pelo port. O stage-qa verifica problemas comuns como shebang incorretas, links simbólicos apontando para fora do diretório de stage, arquivos setuid e bibliotecas não removidas... Esses testes não encontrarão caminhos codificados dentro dos arquivos do port, nem verificarão se o LOCALBASE está sendo usado para se referir corretamente a arquivos de outros ports. O port instalado temporariamente em /var/tmp/`make -V PORTNAME` deve ser testado quanto à operação correta para garantir que não haja problemas com os caminhos. O PREFIX não deve ser definido explicitamente em um Makefile do port. Usuários instalando o port podem ter definido a variável PREFIX para um local personalizado e o port deve respeitar essa configuração. Referencie programas e arquivos de outros ports com as variáveis ​​mencionadas acima, não com nomes de caminho explícitos. Por exemplo, se o port exigir uma macro PAGER para ter o nome de caminho completo para o less, não use um caminho literal para /usr/local/bin/less. Em vez disso, use ${LOCALBASE}: -DPAGER=\"${LOCALBASE}/bin/less\" O caminho com LOCALBASE é muito provável que ainda funcione se o administrador do sistema mudou toda a arvore /usr/local para algum outro lugar. Todos esses testes são feitos automaticamente ao executar poudriere testport ou poudriere bulk -t. É altamente recomendável que cada contribuidor de ports instale e teste seus ports com ele. Veja para maiores informações. <application>Poudriere</application> Para um contribuidor de ports, o Poudriere é uma das mais importantes e úteis ferramentas de teste e compilação. Suas principais características incluem: Compilação em massa de toda a árvore de ports, subconjuntos específicos da árvore de ports, ou um único port incluindo suas dependências Empacotamento automático do resultados de compilação Geração de arquivos de log de compilação por port Fornecer um repositório pkg8 assinado Testar a compilação do port antes de enviar um patch para o rastreador de bugs do FreeBSD ou antes de fazer o commit para a árvore de ports Testar a compilação bem-sucedida de ports usando opções diferentes Porque o Poudriere realiza a sua compilação em um ambiente de jail8 limpo e usa características do zfs8, ele tem várias vantagens sobre os testes tradicionais no sistema host: Ele não polui o ambiente do host: sem arquivos sobrando, sem remoções acidentais, sem alterações nos arquivos de configuração existentes. Ele verifica o pkg-plist para entradas ausentes ou supérfluas Committers de ports às vezes pedem um log do Poudriere juntamente com a apresentação de um patch para avaliar se o patch está pronto para integração na árvore de ports Ele também é muito simples de configurar e usar, não tem dependências e será executado em qualquer versão suportada do FreeBSD. Esta seção mostra como instalar, configurar e executar o Poudriere como parte do fluxo de trabalho normal de um contribuidor de ports. Os exemplos nesta seção mostram um layout de arquivo padrão, como padrão no FreeBSD. Substitua quaisquer alterações locais de acordo. A árvore de ports, representada por ${PORTSDIR}, está localizada em /usr/ports. Ambos ${LOCALBASE} e ${PREFIX} são /usr/local por padrão. Instalando o <application>Poudriere</application> O Poudriere está disponível na árvore de ports em ports-mgmt/poudriere. Ele pode ser instalado usando o pkg8 ou a partir do ports: # pkg install poudriere ou # make -C /usr/ports/ports-mgmt/poudriere install clean Há também uma versão de trabalho em andamento do Poudriere que acabará por se tornar o próximo release. Ele está disponível em ports-mgmt/poudriere-devel. Esta versão de desenvolvimento é usada para as compilações oficiais de pacotes do FreeBSD, então é bem testada. Muitas vezes tem novos recursos interessantes. Um committer de ports desejará usar a versão de desenvolvimento porque é o que é usado na produção e possui todos os novos recursos que farão com que tudo esteja exatamente correto. Um colaborador não precisará necessariamente deles, pois as correções mais importantes são sempre incorporadas na versão release. A principal razão para o uso da versão de desenvolvimento para compilar os pacotes oficiais é porque é mais rápido, de uma forma que encurtará uma compilação completa de 18 horas para 17 horas ao usar um servidor de 32 CPUs high-end com 128GB de RAM. Essas otimizações não terão muita importância ao compilar ports em uma máquina desktop. Configurando o <application>Poudriere</application> O port instala um arquivo de configuração padrão, o /usr/local/etc/poudriere.conf. Cada parâmetro é documentado no arquivo de configuração em poudriere8. Aqui está um arquivo de configuração mínimo de exemplo: ZPOOL=tank ZROOTFS=/poudriere BASEFS=/poudriere DISTFILES_CACHE=/usr/ports/distfiles RESOLV_CONF=/etc/resolv.conf FREEBSD_HOST=ftp://ftp.freebsd.org SVN_HOST=svn.FreeBSD.org ZPOOL O nome do pool de armazenamento do ZFS que o Poudriere deve usar. Deve ser listado na saída de zpool status ZROOTFS A raiz dos sistemas de arquivos gerenciados do Poudriere. Esta entrada fará com que o Poudriere crie o sistema de arquivo zfs8 sob tank/poudriere. BASEFS O ponto de montagem da raiz do sistema de arquivo Poudriere. Esta entrada fará com que o Poudriere monte o tank/poudriere no /poudriere. DISTFILES_CACHE Define onde os distfiles são armazenados. Neste exemplo, o Poudriere e o host compartilham o diretório de armazenamento dos distfiles. Isso evita o download de tarballs que já estão presentes no sistema. RESOLV_CONF Utiliza o /etc/resolv.conf do host dentro do jails para a resolução de DNS. Isso é necessário para que as jails possam resolver as URLs dos distfiles durante o download. Não é necessário ao usar um proxy. Consulte o arquivo de configuração padrão para a configuração de proxy. FREEBSD_HOST O servidor FTP/HTTP a ser usado quando as jails são instaladas a partir de versões do FreeBSD e atualizadas com o freebsd-update8. Escolha um servidor cuja localização esteja próxima, por exemplo, se a máquina estiver localizada na Austrália, use ftp.au.freebsd.org. SVN_HOST O servidor de onde as jails são instaladas e atualizadas ao usar o Subversion. Também usado para a árvore de ports quando não estiver usando o portsnap8. Mais uma vez, escolha um local próximo. Uma lista de espelhos oficiais do Subversion podem ser encontrados na seção sobre Subversion do Handbook do FreeBSD. Criando <application>Poudriere</application> Jails Crie as jails de base que serão usadas pelo Poudriere para as compilações: # poudriere jail -c -j 111Ramd64 -v 11.1-RELEASE -a amd64 Busca a versão 11.1-RELEASE para amd64 do servidor FTP dado por FREEBSD_HOST dentro do poudriere.conf, crie o sistema de arquivos com zfs em tank/poudriere/jails/111Ramd64, monta-o em /poudriere/jails/111Ramd64 e extrai os tarballs 11.1-RELEASE neste sistema de arquivos. # poudriere jail -c -j 11i386 -v stable/11 -a i386 -m svn+https Criado o tank/poudriere/jaulas/11i386 monte-o em /poudriere/jails/11i386, então confira a dica do Subversion branch do FreeBSD-11-STABLE a partir do SVN_HOST dentro do poudriere.conf para dentro de /poudriere/jails/11i386/usr/src, e então complete um buildworld e instale-o em /poudriere/jails/11i386. Se uma determinada revisão do Subversion é necessária, anexe ela à string de versão. Por exemplo: # poudriere jail -c -j 11i386 -v stable/11@123456 -a i386 -m svn+https Embora seja possível compilar uma versão mais nova do FreeBSD em uma versão mais antiga, na maioria das vezes ela não irá executar. Por exemplo, se uma jail stable/11 é necessária, o host terá que rodar stable/11 também. Rodar 11.0-RELEASE não é o suficiente. Para criar uma jail Poudriere para o 12.0-CURRENT: # poudriere jail -c -j 12amd64 -v head -a amd64 -m svn+https Para executar uma jail 12.0-CURRENT no Poudriere você deve estar rodando o 12.0-CURRENT. Em geral, novos kernels podem ser compilados e executar jails mais antigas. Por exemplo, um kernel 12.0-CURRENT pode compilar e executar uma jail 11.1-STABLE no Poudriere se a opção de kernel COMPAT_FREEBSD11 tiver sido compilada (habilitada por padrão na configuração do kernel GENERIC do 12.0-CURRENT). O protocolo padrão svn funciona normalmente, mas não é muito seguro. Usar svn+https juntamente com a verificação do fingerpprint SSL do servidor remoto é aconselhável. Isso garantirá que os arquivos usados para compilar a jail sejam de uma fonte confiável. Uma lista de jails atualmente conhecidas pelo Poudriere podem ser mostradas com poudriere jail -l: # poudriere jail -l JAILNAME VERSION ARCH METHOD 111Ramd64 11.1-RELEASE amd64 ftp 11i386 11.0-STABLE i386 svn+https Mantendo as Jails do <application>Poudriere</application> Atualizadas Gerenciar atualizações é muito simples. O comando: # poudriere jail -u -j JAILNAME atualiza a jail especificada para a versão mais recente disponível. Para releases do FreeBSD, atualiza para o patchlevel mais recente com o freebsd-update8. Para versões do FreeBSD compiladas a partir do código fonte, atualiza para a revisão mais recente na branch do Subversion. Para jails que empregam um método svn+*, é útil adicionar -J NumberOfParallelBuildJobs para acelerar a compilação aumentando o número de trabalhos de compilação paralelos utilizados. Por exemplo, se a máquina de compilação tiver 6 CPUs, use: # poudriere jail -u -J 6 -j JAILNAME Configurando a Árvores de Ports para Uso com o <application>Poudriere</application> Existem várias maneiras de usar árvores de ports no Poudriere. A maneira mais direta é o Poudriere criar uma árvore de ports padrão para si mesmo: # poudriere ports -c Este comando cria o tank/poudriere/ports/default, monta-o em /poudriere/ports/default e o povoa usando o portsnap8. Depois disso, ele é incluído na lista de árvores de ports conhecidas: # poudriere ports -l PORTSTREE METHOD PATH default portsnap /poudriere/ports/default Note que a árvore de ports default é especial. Cada um dos comandos de compilação explicados posteriormente usará implicitamente essa árvore de ports, a menos que seja especificamente especificado de outra forma. Para usar outra árvore, adicione -p treename aos comandos. Embora seja útil para compilações em massa regulares, ter esta árvore de ports padrão com o método portsnap8 pode não ser a melhor maneira de lidar com modificações locais para um contribuidor de ports. Assim como na criação dos jails, é possível usar um método diferente para criar a árvore de ports. Para adicionar uma árvore de ports adicional para testar modificações locais e para o desenvolvimento de ports, é possível baixar a árvore via Subversion: # poudriere ports -c -m svn+https -p subversive Os métodos http e https precisam que o devel/subversion seja compilado com a opção SERF ativada. Ela vem habilitada por padrão. Cria tank/poudriere/ports/subversive e o monta em /poudriere/ports/subversive. Em seguida, ele é povoado usando Subversion. Finalmente, ele é adicionado à lista de árvores de ports conhecidas: # poudriere ports -l PORTSTREE METHOD PATH default portsnap /poudriere/ports/default subversive svn+https /poudriere/ports/subversive O método svn permite qualificadores extras para dizer ao Subversion exatamente como buscar os dados. Isso é explicado em poudriere8. Por exemplo, poudriere ports -c -m svn+ssh -p subversive usa o SSH para o checkout. Usando Árvores de Ports Gerenciadas Manualmente com o Poudriere Dependendo do fluxo de trabalho, pode ser extremamente útil usar árvores de ports que são mantidas manualmente. Por exemplo, se houver uma cópia local da árvore de ports em /work/ports, aponte o Poudriere para o local: # poudriere ports -c -F -f none -M /work/ports -p development Isto será listado na tabela de árvores conhecidas: # poudriere ports -l PORTSTREE METHOD PATH development - /work/ports O traço na coluna METHOD significa que o Poudriere nunca irá atualizar ou alterar esta árvore de ports. É de responsabilidade total do usuário a manutenção desta árvore, incluindo todas as modificações locais que podem ser usadas para testar novos ports e enviar patches. Mantendo as Árvores de Ports do Poudriere Atualizadas Tão simples quanto com as jails descritas anteriormente: # poudriere ports -u -p PORTSTREE Vai atualizar a PORTSTREE, uma árvore dada pela saída de poudriere -l, para a última revisão disponível nos servidores oficiais. As arvores de ports sem um método, veja , não podem ser atualizadas assim. Elas devem ser atualizadas manualmente pelo mantenedor de ports. Testando Ports Depois que as jails e as árvores de ports foram configuradas, o resultado das modificações de um colaborador na árvore de ports pode ser testado. Por exemplo, modificações locais no port www/firefox localizado em /work/ports/www/firefox pode ser testado na jail 11.1-RELEASE criada anteriormente: # poudriere testport -j 111Ramd64 -p development -o www/firefox Isso irá compilar todas as dependências do firefox. Se uma dependência foi criada anteriormente e ainda está atualizada, o pacote pré-criado é instalado. Se uma dependência não tiver um pacote atualizado, ela será compilada com opções padrão em uma jail. Depois disso o firefox será compilado. A compilação completa de cada port será registrada em /poudriere/data/logs/bulk/111Ri386-development/build-time/logs. O nome do diretório 111Ri386-development é derivado dos argumentos para -j e -p, respectivamente. Por conveniência, um link simbólico /poudriere/data/logs/bulk/111Ri386-development/latest também é mantido. O link aponta para o mais recente diretório build-time. Neste diretório também se encontra um index.html para que possa ser possível observar o processo de compilação com um navegador web. Por padrão, o Poudriere limpa as jails e deixa os arquivos de log nos diretórios mencionados acima. Para facilitar a investigação, as jails podem ser mantidas em execução após a compilação, adicionando a opção ao testport: # poudriere testport -j 111Ramd64 -p development -i -o www/firefox Depois que a compilação é concluída, e independentemente de ter sido bem-sucedida, um shell é fornecido dentro da jail. O shell é usado para investigações adicionais. O Poudriere pode ser dito para deixar a jail em execução após a conclusão da compilação com . O Poudriere mostrará o comando para ser executado quando a jail não for mais necessária. E então é possível fazer um jexec8 para dentro dele: # poudriere testport -j 111Ramd64 -p development -I -o www/firefox [...] ====>> Installing local Pkg repository to /usr/local/etc/pkg/repos ====>> Leaving jail 111Ramd64-development-n running, mounted at /poudriere/data/.m/111Ramd64-development/ref for interactive run testing ====>> To enter jail: jexec 111Ramd64-development-n env -i TERM=$TERM /usr/bin/login -fp root ====>> To stop jail: poudriere jail -k -j 111Ramd64 -p development # jexec 111Ramd64-development-n env -i TERM=$TERM /usr/bin/login -fp root # [do some stuff in the jail] # exit # poudriere jail -k -j 111Ramd64 -p development ====>> Umounting file systems Uma parte integral da infraestrutura de compilação de ports do FreeBSD é a capacidade de ajustar os ports as preferências pessoais por meio de opções. Elas podem ser testadas com o Poudriere também. Adicionando a opção : # poudriere testport -c -o www/firefox Apresenta o diálogo de configuração do port antes que o port seja compilado. Os ports informados após o no formato category/portname usará as opções especificadas, todas as dependências usarão as opções padrão. O teste de ports dependentes com opções não padrão pode ser realizado usando conjuntos, consulte . Ao testar ports nos quais o pkg-plist é alterado durante a compilação, dependendo das opções selecionadas, é recomendável executar um teste com todas as opções selecionadas e um com todas as opções desmarcadas. Usando Conjuntos Para todas as ações envolvendo builds, um então chamado conjunto pode ser especificado usando -z setname. Um conjunto se refere a uma compilação totalmente independente. Isso permite, por exemplo, o uso de testport com opções não padrão para os ports dependentes. Para usar sets, o Poudriere espera uma estrutura de diretórios existente semelhante a PORT_DBDIR, o padrão é /var/db/ports no seu diretório de configuração. Este diretório é então nullfs5-montado nas jails onde os ports e suas dependências são compilados. Normalmente, um ponto de partida adequado pode ser obtido copiando de forma recursiva o PORT_DBDIR para /usr/local/etc/poudriere.d/jailname-portname-setname-options. Isso é descrito em detalhes em poudriere8. Por exemplo, para testar o www/firefox em um conjunto específico chamado devset, adicione o parâmetro -z devset ao comando testport: # poudriere testport -j 111Ramd64 -p development -z devset -o www/firefox Isso irá procurar pela existência desses diretórios nesta ordem: /usr/local/etc/poudriere.d/111Ramd64-development-devset-options /usr/local/etc/poudriere.d/111Ramd64-devset-options /usr/local/etc/poudriere.d/111Ramd64-development-options /usr/local/etc/poudriere.d/devset-options /usr/local/etc/poudriere.d/development-options /usr/local/etc/poudriere.d/111Ramd64-options /usr/local/etc/poudriere.d/options Desta lista, o Poudriere nullfs5-monta a primeira árvore existente de diretório para o diretório /var/db/ports das jails de compilação. Portanto, todas as opções personalizadas são usadas para todos os ports durante essa execução do testport. Depois que a estrutura de diretório para um conjunto é fornecida, as opções para um port específico podem ser alteradas. Por exemplo: # poudriere options -c www/firefox -z devset O diálogo de configuração para o www/firefox é mostrado e as opções podem ser editadas. As opções selecionadas são salvas no set devset. Poudriere é muito flexível na configuração das opções. Elas podem ser configuradas para jails específicas, árvores de ports e para vários ports por um comando. Veja poudriere8 para detalhes. Fornecendo um Arquivo <filename>make.conf</filename> Customizado Semelhante ao uso de conjuntos (sets), o Poudriere também usará um make.conf personalizado se for fornecido. Nenhum argumento de linha de comando especial é necessário. Em vez disso, o Poudriere procura por arquivos existentes que correspondam a um esquema de nomes derivado da linha de comando. Por exemplo: # poudriere testport -j 111Ramd64 -p development -z devset -o www/firefox faz o Poudriere verificar a existência desses arquivos nesta ordem: /usr/local/etc/poudriere.d/make.conf /usr/local/etc/poudriere.d/devset-make.conf /usr/local/etc/poudriere.d/development-make.conf /usr/local/etc/poudriere.d/111Ramd64-make.conf /usr/local/etc/poudriere.d/111Ramd64-development-make.conf /usr/local/etc/poudriere.d/111Ramd64-devset-make.conf /usr/local/etc/poudriere.d/111Ramd64-development-devset-make.conf Ao contrário dos conjuntos, todos os arquivos encontrados serão anexados, naquela ordem, em um make.conf dentro das jails de compilação. Assim, é possível ter variáveis ​​gerais, destinadas a afetar todas as compilações /usr/local/etc/poudriere.d/make.conf. Variáveis ​​especiais, destinadas a afetar apenas determinadas jails ou conjuntos, podem ser setadas em arquivos especiais como make.conf, assim como /usr/local/etc/poudriere.d/111Ramd64-development-devset-make.conf. Usando <filename>make.conf</filename> para Alterar o <application>Perl</application> Padrão Para compilar um conjunto com uma versão não padrão do Perl, por exemplo, 5.20, usando um conjunto chamado perl5-20, crie um perl5-20-make.conf com esta entrada: DEFAULT_VERSIONS+= perl=5.20 Observe o uso de += de modo que, se a variável já estiver definida no make.conf padrão, seu conteúdo não será sobrescrito. Remoção de Distfiles Não Mais Necessários Poudriere vem com um mecanismo embutido para remover distfiles desatualizados que não são mais usados ​​por qualquer port de uma determinada árvore. O comando # poudriere distclean -p portstree irá escanear a pasta distfiles, DISTFILES_CACHE dentro do poudriere.conf, contra a árvore de ports dada pelo argumento -p portstree e solicitar a remoção desses distfiles. Para pular o prompt e remover incondicionalmente todos os arquivos não utilizados, o argumento -y pode ser adicionado: # poudriere distclean -p portstree -y Atualizando um Port Quando um port não estiver na versão mais recente disponibilizada pelos autores, atualize a sua cópia de trabalho local do /usr/ports. O port pode já ter sido atualizado para a nova versão. Ao trabalhar com diversos ports, provavelmente será mais fácil usar o Subversion para manter toda a coleção de ports atualizada, conforme descrito no Handbook. Isso trará o benefício adicional de rastrear todas as dependências de ports. O próximo passo é ver se há uma atualização já pendente. Para fazer isso, existem duas opções. Há uma interface de pesquisa no Relatório de Problemas do FreeBSD (PR) ou banco de dados de bugs. Selecione Ports & Packages no menu de seleção múltipla Product e digite o nome do port no campo Summary. No entanto, às vezes as pessoas esquecem de colocar o nome do port no campo Resumo de maneira não ambígua. Nesse caso, tente pesquisar o campo Comment na seção Detailled Bug Information, ou tente o Sistema de Monitoramento de Ports do FreeBSD (também conhecido como portsmon). Este sistema tenta classificar os PRs do port por portname. Para procurar por PRs sobre um port específico, use a Visão geral de um port. Se não houver nenhum PR pendente, o próximo passo é enviar um email para o mantenedor do port, como apresentado em make maintainer. Essa pessoa pode já estar trabalhando em uma atualização ou ter algum motivo para não atualizar o port neste momento (devido a, por exemplo, problemas de estabilidade da nova versão), e não há necessidade de duplicar seu trabalho. Note que os ports não mantidos são listadas com um mantenedor ports@FreeBSD.org, que é apenas a lista de discussão geral de ports, então enviar emails provavelmente não ajudará nesse caso. Se o mantenedor lhe pedir para fazer a atualização ou não houver mantenedor, então ajude o FreeBSD preparando a atualização! Por favor, faça isso usando o comando diff1 do sistema base. Para criar um diff adequado para um único patch, copie o arquivo que precisa de patching para something.orig, salve as alterações em something e depois crie o patch: % diff -u something.orig something > something.diff Caso contrário, use o método svn diff () ou copie o conteúdo do port para um diretório completamente diferente e use o resultado do diff1 recursivo para os diretórios novos e antigos do port (por exemplo, se o diretório de ports modificado for chamado superedit e o original está na nossa árvore como superedit.bak então salve o resultado do comando diff -ruN superedit.bak superedit). Tanto o diff unificado ou como o de contexto é aceito, mas os committers do port geralmente preferem diffs unificados. Observe o uso da opção -N -- essa é a maneira correta de forçar o diff a lidar adequadamente com o caso de novos arquivos sendo adicionados ou de arquivos antigos sendo excluídos. Antes de nos enviar o diff, por favor, examine a saída para se certificar de que todas as alterações fazem sentido. (Em particular, primeiro limpe os diretórios de trabalho com make clean). Se alguns arquivos foram adicionados, copiados, movidos ou removidos, adicione essas informações ao relatório de problemas, para que o committer que pegar o patch saiba quais comandos svn1 executar. Para simplificar operações comuns com arquivos de patch, use make makepatch como descrito em . Existem outras ferramentas, como /usr/ports/Tools/scripts/patchtool.py. Antes de usá-lo, por favor leia /usr/ports/Tools/scripts/README.patchtool. Se o port não é mantido e você o utiliza ativamente, por favor, considere se voluntariar como o seu mantenedor. O FreeBSD tem mais de 4000 ports sem mantenedores, e esta é uma área onde mais voluntários são sempre necessários. (Para uma descrição detalhada das responsabilidades dos mantenedores, consulte a seção no Developer's Handbook. Para enviar o diff, use o formulário de envio de bugs (no produto Ports & Packages, e no componente Individual Port(s)). Se o remetente também estiver mantendo o port, certifique-se de colocar [MAINTAINER] no início da linha de Summary. Sempre inclua a categoria com o nome do port, seguido por dois pontos e uma breve descrição do problema. Por exemplo: category/portname: add FOO option, ou se você for o mantenedor do port, [MAINTAINER] category/portname: Update to XY. Por favor mencione quaisquer arquivos adicionados ou deletados na mensagem, pois eles devem ser explicitamente especificados no svn1 ao fazer o commit. Não comprima ou codifique o diff. Antes de enviar o bug, revise a seção Escrevendo um relatório de problema no artigo Relatórios de Problemas. Ele contém muito mais informações sobre como escrever relatórios úteis de problemas. Se a atualização for motivada por preocupações de segurança ou por uma falha grave em um port que já está disponível na arvore, notifique a Equipe de Gerenciamento de Ports portmgr@FreeBSD.org para solicitar imediata recompilação e redistribuição do pacote do port. Caso contrário, usuários desavisados ​​do pkg continuarão a instalar a versão antiga via pkg install por várias semanas. Por favor, use o diff1 ou svn diff para criar atualizações para ports existentes. Outros formatos incluem o arquivo inteiro e impossibilitam ver o que mudou. Quando os diffs não são incluídos, toda a atualização pode ser ignorada. Agora que tudo isso foi feito, leia sobre como manter-se atualizado . Usando o <application>Subversion</application> para Criar Patches Quando possível, envie por favor um svn1diff. Eles são mais fáceis de manusear do que os diffs entre diretórios novos e antigos. Nele é mais fácil de ver o que mudou e também é mais fácil de atualizar o diff no caso de algo ter sido modificado na Coleção de Ports desde que o diff foi gerado, ou no caso do committer pedir que algo seja corrigido. Além disso, um patch gerado com svn diff pode ser facilmente aplicado com svn patch e irá economizar algum tempo para o committer. % cd ~/my_wrkdir % svn co https://svn.FreeBSD.org/ports/head/dns/pdnsd % cd ~/my_wrkdir/pdnsd Isso pode ser em qualquer lugar, é claro. Compilações de ports não se limitam ao /usr/ports/. O svn.FreeBSD.org é o servidor Subversion público do FreeBSD. Veja Mirrors do Subversion para mais informações. Enquanto estiver no diretório de ports, faça as alterações necessárias. Se você adicionar, copiar, mover ou remover um arquivo, use o svn para registrar essas alterações: % svn add new_file % svn copy some_file file_copy % svn move old_name new_name % svn remove deleted_file Certifique-se de verificar o port usando a lista de verificação e . % svn status % svn update Isso tentará mesclar as diferenças entre o patch e a versão do repositório atual. Veja a saída cuidadosamente. A letra na frente de cada nome de arquivo indica o que foi feito com ele. Consulte para uma lista completa. Prefixos de Atualização de Arquivos do <application>Subversion</application> U O arquivo foi atualizado sem problemas. G O arquivo foi atualizado sem problemas (somente quando está trabalhando com um repositório remoto). M O arquivo foi modificado e foi mesclado sem conflitos. C O arquivo foi modificado e foi mesclado com conflitos.
E se o status C for exibido como resultado de um svn update, isso significa que algo mudou no repositório Subversion e o svn1 não foi capaz de mesclar as alterações locais com as do repositório. É sempre uma boa ideia inspecionar as alterações de qualquer maneira, o svn1 não sabe nada sobre a estrutura de um port, então pode (e provavelmente irá) mesclar coisas que não fazem sentido. O último passo é fazer um diff1 unificado das mudanças: % svn diff > ../`make -VPKGNAME`.diff Se os arquivos foram adicionados, copiados, movidos ou removidos, inclua os comandos svn1 add, copy, move e remove que foram usados. O svn move ou o svn copy deve ser executado antes de aplicar o patch. O svn add ou svn remove deve ser executado após o patch ser aplicado. Envie o patch seguindo as diretrizes de envios de relatórios de problemas. <filename>UPDATE</filename> e <filename>MOVED</filename> <filename>/usr/ports/UPDATING</filename> Se a atualização do port exigir etapas especiais, como alteração de arquivos de configuração ou execução de um programa específico, ela deverá ser documentada neste arquivo. O formato de uma entrada neste arquivo é: YYYYMMDD: AFFECTS: users of portcategory/portname AUTHOR: Your name <Your email address> Special instructions Quando incluir instruções exatas para o portmaster, portupgrade e/ou instruções ao pkg, por favor, certifique-se de escapar o shell escaping corretamente. Por exemplo, não use: # pkg delete -g -f docbook-xml* docbook-sk* docbook[2345]??-* docbook-4* Como mostrado, o comando só irá funcionar com bourne shells. Em vez disso, use o formato abaixo, que funcionará com ambos bourne shell e c-shell: # pkg delete -g -f docbook-xml\* docbook-sk\* docbook\[2345\]\?\?-\* docbook-4\* Recomenda-se que a linha AFFECTS contenha uma glob que corresponda a todos os ports afetados pela entrada, para que as ferramentas automatizadas possam analisá-la com a maior facilidade possível. Se uma atualização diz respeito a todas as versõs do BIND 9 o conteúdo de AFFECTS deve ser usuários do dns/bind9*, não deve ser usuários do BIND 9 <filename>/usr/ports/MOVED</filename> Este arquivo é usado para listar os ports movidos ou removidos. Cada linha no arquivo é composta por nome do port, para onde o port foi movido, quando e por quê. Se o port foi removido, a seção detalhando onde ele estava pode ser deixado em branco. Cada seção deve ser separada pelo caractere | (pipe), assim: old name|new name (blank for deleted)|date of move|reason A data deve ser inserida no formato YYYY-MM-DD. Novas entradas são adicionadas ao final da lista para mantê-las em ordem cronológica, com a entrada mais antiga no topo da lista. Se um port foi removido, e depois restaurado, exclua a linha neste arquivo que informa que ele foi removido. Se um port foi renomeado e depois renomeado de volta para seu nome original, adicione uma nova entrada com o nome intermediário para o nome antigo e remova a entrada antiga para não criar um loop. Quaisquer alterações devem ser validadas com Tools/scripts/MOVEDlint.awk. Se estiver usando um diretório de ports diferente de /usr/ports, use: % cd /home/user/ports % env PORTSDIR=$PWD Tools/scripts/MOVEDlint.awk Segurança Por Que Segurança é Tão Importante Bugs ocasionalmente são inseridos em software. Indiscutivelmente, os mais perigosos deles são aqueles que abrem vulnerabilidades de segurança. Do ponto de vista técnico, tais vulnerabilidades devem ser fechadas exterminando os bugs que as causam. No entanto, as políticas para lidar com meros bugs e vulnerabilidades de segurança são muito diferentes. Um bug pequeno típico afeta apenas os usuários que ativaram alguma combinação de opções que acionam o bug. O desenvolvedor acabará lançando um patch seguido de uma nova versão do software, livre do bug, mas a maioria dos usuários não irá se incomodar em fazer a atualização de imediato porque o bug nunca os incomodou. Um bug crítico que pode causar perda de dados representa um problema grave. No entanto, usuários prudentes sabem que muitos acidentes são possíveis, e que além de erros de software, podem levar à perda de dados, e portanto eles fazem backups dos dados importantes, além disso, um bug crítico será descoberto muito rapidamente. Uma vulnerabilidade de segurança é diferente. Primeiro, ela pode permanecer despercebida por anos, porque geralmente não causa mau funcionamento do software. Segundo, uma parte mal-intencionada pode usá-la para obter acesso não autorizado a um sistema vulnerável, para destruir ou alterar dados confidenciais; no pior dos casos, o usuário nem notará os danos causados. Terceiro, expor um sistema vulnerável geralmente ajuda os invasores a invadir outros sistemas que não poderiam ser comprometidos de outra forma. Portanto, fechar uma vulnerabilidade por si só não é suficiente: notifique a audiência afetada da maneira mais clara e abrangente, o que lhes permitirá avaliar o perigo e tomar as medidas adequadas. Corrigindo Vulnerabilidades de Segurança Embora seja sobre o assunto de ports e pacotes, uma vulnerabilidade de segurança pode inicialmente aparecer na distribuição original ou nos arquivos do port. No primeiro caso, o desenvolvedor de software original provavelmente lançará um patch ou uma nova versão instantaneamente. Atualize o port prontamente com relação à correção do autor. Se a correção for atrasada por algum motivo, marque o port como FORBIDDEN ou adicione um arquivo patch no port. No caso de um port vulnerável, conserte o port o mais rápido possível. Em ambos os casos, siga o procedimento padrão para enviar alterações a menos que tenha direitos para enviá-lo diretamente para a árvore de ports. Ser um committer de ports não é suficiente para fazer um commit em um port arbitrário. Lembre-se que os ports geralmente possuem mantenedores, e eles devem ser respeitados. Por favor, certifique-se de que a revisão do port é incrementada assim que a vulnerabilidade for fechada. É assim que os usuários que atualizam pacotes regularmente verão que precisam executar uma atualização. Além disso, um novo pacote será compilado e distribuído por FTP e mirrors WWW, substituindo o vulnerável. Atualize PORTREVISION a menos que tenha mudado o DISTVERSION durante a correção da vulnerabilidade. Isso é, incremente PORTREVISION se adicionar um arquivo de patch ao port, mas não o incremente se atualizar o port para a versão mais recente do software, pois DISTVERSION já terá sido alterado. Por favor, consulte a seção correspondente para mais informações. Mantendo a Comunidade Informada O Banco de Dados VuXML Uma medida muito importante e urgente a ser tomada o mais cedo possível ao descobrir uma vulnerabilidade de segurança é notificar a comunidade de usuários de port sobre o perigo. Essa notificação serve a dois propósitos. Primeiro, se o perigo for realmente severo, será prudente aplicar uma solução instantânea. Por exemplo, parar o serviço de rede afetado ou até mesmo desinstalar o port completamente até que a vulnerabilidade seja fechada. Segundo, muitos usuários tendem a atualizar pacotes instalados apenas ocasionalmente. Eles saberão pela notificação que eles devem atualizar o pacote o quanto antes assim que uma versão com a correção estiver disponível. Dado o grande número de ports na árvore, um aviso de segurança não pode ser emitido em cada incidente sem criar um flood e perder a atenção do público quando se tratar de assuntos realmente sérios. Portanto, vulnerabilidades de segurança encontradas em ports são registradas no banco de dados VuXML do FreeBSD. Os membros do Security Officer Team também monitoram os problemas que requerem suas intervenções. Committers podem eles mesmos atualizar o banco de dados VuXML, ajudar o Security Officer Team e fornecer informações cruciais para a comunidade mais rapidamente. Aqueles que não são committers ou que descobriram uma vulnerabilidade excepcionalmente severa não devem hesitar em contatar o Security Officer Team diretamente, conforme descrito na página Informações de Segurança do FreeBSD. O banco de dados VuXML é um documento XML. Seu arquivo fonte vuln.xml é mantido dentro do port security/vuxml. Portanto, o caminho completo do arquivo será PORTSDIR/security/vuxml/vuln.xml. Toda vez que uma vulnerabilidade de segurança é descoberta em um port, favor adicionar uma entrada para ela nesse arquivo. Até que esteja familiarizado com o VuXML, a melhor coisa a fazer é encontrar uma entrada existente que seja parecida, depois copiá-la e usá-la como modelo. Uma Breve Introdução ao VuXML O formato XML completo é complexo e está muito além do escopo deste livro. No entanto, para obter informações básicas sobre a estrutura de uma entrada VuXML, apenas a noção de tags é necessária. Os nomes de tags XML são colocados entre colchetes angulares. Cada abertura <tag> deve ter um fechamento correspondente </tag>. As tags podem ser aninhadas. Se aninhadas, as tags internas devem ser fechadas antes das externas. Há uma hierarquia de tags, ou seja, regras mais complexas de aninhamento. Isso é semelhante ao HTML. A principal diferença é que o XML é eXtensible, isto é, com base na definição de tags personalizadas. Devido à sua estrutura intrínseca, o XML por outro lado coloca dados amórficos de uma maneira mais organizada. O VuXML é especialmente adaptado para marcar descrições de vulnerabilidades de segurança. Agora considere uma entrada VuXML realista: <vuln vid="f4bc80f4-da62-11d8-90ea-0004ac98a7b9"> <topic>Several vulnerabilities found in Foo</topic> <affects> <package> <name>foo</name> <name>foo-devel</name> <name>ja-foo</name> <range><ge>1.6</ge><lt>1.9</lt></range> <range><ge>2.*</ge><lt>2.4_1</lt></range> <range><eq>3.0b1</eq></range> </package> <package> <name>openfoo</name> <range><lt>1.10_7</lt></range> <range><ge>1.2,1</ge><lt>1.3_1,1</lt></range> </package> </affects> <description> <body xmlns="http://www.w3.org/1999/xhtml"> <p>J. Random Hacker reports:</p> <blockquote cite="http://j.r.hacker.com/advisories/1"> <p>Several issues in the Foo software may be exploited via carefully crafted QUUX requests. These requests will permit the injection of Bar code, mumble theft, and the readability of the Foo administrator account.</p> </blockquote> </body> </description> <references> <freebsdsa>SA-10:75.foo</freebsdsa> <freebsdpr>ports/987654</freebsdpr> <cvename>CAN-2010-0201</cvename> <cvename>CAN-2010-0466</cvename> <bid>96298</bid> <certsa>CA-2010-99</certsa> <certvu>740169</certvu> <uscertsa>SA10-99A</uscertsa> <uscertta>SA10-99A</uscertta> <mlist msgid="201075606@hacker.com">http://marc.theaimsgroup.com/?l=bugtraq&amp;m=203886607825605</mlist> <url>http://j.r.hacker.com/advisories/1</url> </references> <dates> <discovery>2010-05-25</discovery> <entry>2010-07-13</entry> <modified>2010-09-17</modified> </dates> </vuln> Os nomes das tags devem ser auto explicativos, por isso vamos dar uma olhada apenas nos campos que precisam ser preenchidos: Esta é a tag de nível superior de uma entrada VuXML. Ela tem um atributo obrigatório, vid, especificando um identificador universalmente único (UUID) para essa entrada (entre aspas). Gere um UUID para cada nova entrada VuXML (e não se esqueça de substituí-lo pelo modelo UUID, a menos que esteja escrevendo a entrada desde o início). Use uuidgen1 para gerar um UUID VuXML. Esta é uma descrição de uma linha do problema encontrado. Os nomes dos pacotes afetados são listados nesta tag. Vários nomes podem ser fornecidos, pois vários pacotes podem ser baseados em um único master port ou produto de software. Isso pode incluir branches stable ​​e de desenvolvimento, versões de localidade e slave ports englobando diferentes escolhas de opções importantes de configuração em build-time. É responsabilidade do submitter encontrar todos os pacotes relacionados ao escrever uma entrada VuXML. Tenha em mente que make search name=foo pode ajudar. Os principais pontos a procurar são: a variante foo-devel para um port foo; outras variantes com um sufixo como -a4 (para pacotes relacionados a impressão), -without-gui (para pacotes com suporte ao X desativado) ou similares; jp-, ru-, zh- e outras possíveis variantes de localidade nas categorias nacionais correspondentes da coleção de ports. Versões afetadas de pacote(s) são especificadas com um ou mais intervalos usando uma combinação de elementos <lt>, <le>, <eq>, <ge> e <gt>. Verifique se os intervalos de versão fornecidos não se sobrepõem. Em uma especificação de range, * (asterisco) indica o menor número de versão. Em particular, 2.* é menor do que 2.a. Portanto, um asterisco pode ser usado em um intervalo para corresponder todas as possíveis versões alfa, beta e RC. Por exemplo,<ge>2.*</ge><lt>3.*</lt> irá seletivamente corresponder a cada versão 2.x enquanto <ge>2.0</ge><lt>3.0</lt> não irá, pois a versão 2.r3 será ignorada e a versão 3.b estará dentro do range. O exemplo acima especifica que as versões afetadas vão de 1.6 até 1.9 inclusive, versões 2.x antes de 2.4_1 e versão 3.0b1. Vários grupos de pacotes relacionados (essencialmente, ports) podem ser listados na seção <affected>. Isso pode ser usado se vários produtos de software (como FooBar, FreeBar e OpenBar) crescerem da mesma base de código e ainda compartilharem seus bugs e vulnerabilidades. Observe a diferença de listar vários nomes em uma única seção <package>. Os intervalos de versão têm que incluir PORTEPOCH e PORTREVISION se aplicáveis. Lembre-se que, de acordo com as regras de agrupamento, uma versão com um valor diferente de zero para o PORTEPOCH é maior que qualquer versão sem PORTEPOCH, por exemplo, 3.0,1 é maior que 3.1 ou até mesmo do que 8.9. Este é um resumo do problema. XHTML é usado neste campo. Pelo menos <p> e </p> tem que aparecer. Marcações mais complexas podem ser usadas, mas apenas por uma questão de precisão e clareza: Sem enfeitar, por favor. Esta seção contém referências a documentos relevantes. Quanto mais referências aplicadas, melhor. Isto é um aviso de segurança do FreeBSD. Isto é um relatório de problemas do FreeBSD. Isto é um identificador MITRE CVE. Isto é um ID de bug do SecurityFocus. Isto é um aviso de segurança US-CERT. Isto é uma nota de vulnerabilidade US-CERT. Isto é um alerta de Cyber Segurança US-CERT. Isto é um Alerta Técnico de Cyber Segurança US-CERT. Esta é uma URL para uma postagem arquivada em uma lista de discussão. O atributo msgid é opcional e pode especificar o ID da mensagem no post. Esta é uma URL genérica. Apenas se nenhuma das outras categorias de referência for aplicável. Esta é a data em que o problema foi divulgado (YYYY-MM-DD). Esta é a data quando a entrada foi adicionada (YYYY-MM-DD). Esta é a data em que qualquer informação na entrada foi modificada pela última vez (YYYY-MM-DD). Novas entradas não devem incluir este campo. Adicione-a ao editar uma entrada existente. Testando Alterações no Banco de Dados VuXML Este exemplo descreve uma nova entrada para uma vulnerabilidade no pacote dropbear que foi corrigido na versão dropbear-2013.59. Como pré-requisito, instale uma nova versão do port security/vuxml. Primeiro, verifique se já existe uma entrada para esta vulnerabilidade. Se houvesse essa entrada, ela deveria corresponder com a versão anterior do pacote, 2013.58: % pkg audit dropbear-2013.58 Se não houver nenhuma, adicione uma nova entrada para esta vulnerabilidade. % cd ${PORTSDIR}/security/vuxml % make newentry Verifique sua sintaxe e formatação: % make validate Pelo menos um desses pacotes precisa ser instalado:textproc/libxml2, textproc/jade. Verifique se a seção <affected> da entrada irá coincidir com os pacotes corretos: % pkg audit -f ${PORTSDIR}/security/vuxml/vuln.xml dropbear-2013.58 Certifique-se de que a entrada não produza correspondências incorretas. Agora, verifique se as versões corretas do pacote são correspondidas pela entrada: % pkg audit -f ${PORTSDIR}/security/vuxml/vuln.xml dropbear-2013.58 dropbear-2013.59 dropbear-2012.58 is vulnerable: dropbear -- exposure of sensitive information, DoS CVE: CVE-2013-4434 CVE: CVE-2013-4421 WWW: http://portaudit.FreeBSD.org/8c9b48d1-3715-11e3-a624-00262d8b701d.html 1 problem(s) in the installed packages found. A versão anterior é encontrada enquanto a última não. O Que Fazer e Não Fazer Introdução Aqui está uma lista comum de o que fazer ou não, encontrada durante o processo de portabilidade. Verifique o port com relação a essa lista, mas também verifique os ports no banco de dados de PR's que outros enviaram. Envie quaisquer comentários sobre os ports, conforme descrito em Relatórios de Bugs e Comentários Gerais. Verificar os ports no banco de dados de PR's irá tornar o processo mais rápido para que possamos fazer o seu commit e para provar que você sabe o que está fazendo. <varname>WRKDIR</varname> Não escreva nada em arquivos fora do WRKDIR. WRKDIR é o único lugar garantido com permissão de escrita durante a compilação do port (consulte instalando ports a partir de um CDROM para um exemplo de construção de ports de uma árvore somente leitura). Os arquivos pkg-* podem ser modificados pela redefinição de uma variável em vez de sobrescrever o arquivo. <varname>WRKDIRPREFIX</varname> Certifique-se de que o port honre a variável WRKDIRPREFIX. A maioria dos ports não precisa se preocupar com isso. Em particular, quando se refere a uma variável WRKDIR de outro port, observe que o local correto é WRKDIRPREFIXPORTSDIR/subdir/name/work e não PORTSDIR/subdir/name/work ou .CURDIR/../../subdir/name/work ou algo assim. Além disso, se definir WRKDIR, certifique-se de adicionar ${WRKDIRPREFIX}${.CURDIR} na frente. Diferenciando Sistemas Operacionais e Versões de OS Alguns códigos precisam de modificações ou compilação condicional com base na versão do FreeBSD Unix em que ele está sendo executado. A maneira preferida de distinguir as versões do FreeBSD é usar as macros __FreeBSD_version e __FreeBSD__ definidas em sys/param.h. Se este arquivo não estiver incluído, adicione o código, #include <sys/param.h> para o lugar adequado no arquivo .c. __FreeBSD__ é definido em todas as versões do FreeBSD para seu principal número de versão. Por exemplo, no FreeBSD 9.x, __FreeBSD__ é definido para 9. #if __FreeBSD__ >= 9 # if __FreeBSD_version >= 901000 /* 9.1+ release specific code here */ # endif #endif Uma lista completa de valores __FreeBSD_version está disponível em . Escrevendo Algo Depois do <filename>bsd.port.mk</filename> Não escreva nada depois da linha .include <bsd.port.mk>. Isso geralmente pode ser evitado incluindo bsd.port.pre.mk em algum lugar no meio do Makefile e bsd.port.post.mk no fim. Inclua o par bsd.port.pre.mk/bsd.port.post.mk ou apenas bsd.port.mk; não misture o uso dos dois. bsd.port.pre.mk define apenas algumas variáveis, que podem ser usadas em testes no Makefile, bsd.port.post.mk define o restante. Aqui estão algumas variáveis ​​importantes definidas no arquivo bsd.port.pre.mk (esta não é a lista completa, por favor leia bsd.port.mk para a lista completa). Variável Descrição ARCH A arquitetura retornada por uname -m (por exemplo, i386) OPSYS O tipo de sistema operacional, conforme retornado por uname -s (por exemplo, FreeBSD) OSREL A versão de lançamento do sistema operacional (por exemplo, 2.1.5 ou 2.2.7) OSVERSION A versão numérica do sistema operacional; o mesmo que __FreeBSD_version. LOCALBASE A base da árvore local (por exemplo, /usr/local) PREFIX Onde o port se instala (veja mais sobre a variável PREFIX). Quando MASTERDIR for necessário, sempre o defina antes de incluir o bsd.port.pre.mk. Aqui estão alguns exemplos de coisas que podem ser adicionadas depois do bsd.port.pre.mk: # no need to compile lang/perl5 if perl5 is already in system .if ${OSVERSION} > 300003 BROKEN= perl is in system .endif Sempre use tab em vez de espaços após o argumento BROKEN=. Uso de Declarações <function>exec</function> em Wrapper Scripts Se o port instalar um script shell cuja finalidade é executar outro programa, e se a execução desse programa for a última ação executada pelo script, certifique-se de executar o programa usando a função exec, por exemplo: #!/bin/sh exec %%LOCALBASE%%/bin/java -jar %%DATADIR%%/foo.jar "$@" A declaração de exec substitui o processo do shell pelo programa especificado. E se exec for omitido, o processo do shell permanece na memória enquanto o programa está sendo executado e consome desnecessariamente recursos do sistema. Faça as Coisas Racionalmente O Makefile deve fazer as coisas de uma maneira simples e razoável. Tornar algumas linhas mais curtas ou mais legíveis é sempre melhor. Exemplos incluem usar um construtor .if do make em vez de um construtor if do shell, não redefinir do-extract se redefinir EXTRACT* é o suficiente e usar GNU_CONFIGURE ao invés de CONFIGURE_ARGS += --prefix=${PREFIX}. Se um monte de código novo é necessário para fazer algo, já pode haver uma implementação dele em bsd.port.mk. Embora seja difícil de ler, há muitos problemas aparentemente difíceis para os quais bsd.port.mk já fornece uma solução simples. Respeite Ambos <varname>CC</varname> e <varname>CXX</varname> O port deve respeitar tanto CC e CXX. O que queremos dizer com isso é que o port não deve definir os valores dessas variáveis ​​absolutamente, sobrepondo os valores existentes; em vez disso, pode anexar quaisquer valores necessários aos valores existentes. Isso é para que as opções de build que afetam todos os ports possam ser definidas globalmente. Se o port não respeitar essas variáveis, por favor adicione NO_PACKAGE=ignores either cc or cxx ao Makefile. Aqui está um exemplo do Makefile respeitando ambos CC e CXX. Note o ?=: CC?= gcc CXX?= g++ Aqui está um exemplo que não respeita nem CC nem CXX: CC= gcc CXX= g++ Ambos CC e CXX podem ser definidos em sistemas FreeBSD no arquivo /etc/make.conf. O primeiro exemplo define um valor se não foi definido anteriormente no arquivo /etc/make.conf, preservando quaisquer definições de todo o sistema. O segundo exemplo atrapalha qualquer coisa previamente definida. Respeite <varname>CFLAGS</varname> O port deve respeitar a variável CFLAGS. O que queremos dizer com isso é que o port não deve definir o valor dessa variável absolutamente, substituindo o valor existente. Em vez disso, pode anexar quaisquer valores necessários ao valor existente. Isso é para que as opções de build que afetam todos os ports possam ser definidas globalmente. Se isso não acontecer, por favor adicione NO_PACKAGE=ignores cflags ao Makefile. Aqui está um exemplo de Makefile respeitando CFLAGS. Note o +=: CFLAGS+= -Wall -Werror Aqui está um exemplo que não respeita CFLAGS: CFLAGS= -Wall -Werror CFLAGS são definidas em sistemas FreeBSD no arquivo /etc/make.conf. O primeiro exemplo acrescenta flags adicionais para a variável CFLAGS, preservando quaisquer definições de todo o sistema. O segundo exemplo atrapalha qualquer coisa previamente definida. Remove flags de otimização do Makefile de terceiros. O sistema de variáveis CFLAGS contém flags de otimização de todo o sistema. Um exemplo de um Makefile não modificado: CFLAGS= -O3 -funroll-loops -DHAVE_SOUND Usando flags de otimização do sistema, o Makefile seria semelhante a este exemplo: CFLAGS+= -DHAVE_SOUND Logs de Compilação Detalhados Faz com que o sistema de build dos ports exiba todos os comandos executados durante o estágio de build. Os registros de build completos são cruciais para depurar problemas de ports. Exemplo de log de compilação não informativo (ruim): CC source1.o CC source2.o CCLD someprogram Exemplo de log de compilação detalhado (bom): cc -O2 -pipe -I/usr/local/include -c -o source1.o source1.c cc -O2 -pipe -I/usr/local/include -c -o source2.o source2.c cc -o someprogram source1.o source2.o -L/usr/local/lib -lsomelib Alguns sistemas de build, como o CMake, ninja e GNU configure são configurados para registro detalhado pelo framework do ports. Em outros casos, os ports podem precisar de ajustes individuais. Feedback Envie mudanças aplicáveis e correções ​​para o mantenedor upstream para inclusão na próxima versão do código. Isso torna a atualização para a próxima versão muito mais fácil. <filename>README.html</filename> README.html não faz parte do port, mas é gerado com o comando make readme. Não inclua este arquivo em patches ou commits. Se o comando make readme falhar, certifique-se de que o valor padrão de ECHO_MSG não tenha sido modificado pelo port. Marcando um Port não Instalável com a variável <varname>BROKEN</varname>, <varname>FORBIDDEN</varname> ou <varname>IGNORE</varname> Em certos casos, os usuários devem ser impedidos de instalar um port. Existem várias variáveis ​​que podem ser usadas no Makefile de um port para informar ao usuário que o port não pode ser instalado. O valor dessas variáveis ​​make será o motivo que é mostrado aos usuários do porque o port se recusa a se instalar. Por favor, use a variável correta. Cada variável transmite significados radicalmente diferentes, tanto para usuários quanto para sistemas automatizados que dependem do Makefile, assim como o cluster de compilação de ports, FreshPorts e portsmon. Variáveis BROKEN é reservada para ports que atualmente não compilam, instalam, desinstalam ou que não são executados corretamente. Use-o para ports em que o problema é considerado temporário. Se instruído, o cluster de build ainda tentará compilar eles para ver se o problema subjacente foi resolvido. (No entanto, em geral, o cluster é executado sem isso.) Por exemplo, use BROKEN quando um port: não compila falha em sua configuração ou no processo de instalação instala arquivos fora do ${PREFIX} não remove todos os seus arquivos corretamente após a desinstalação (no entanto, pode ser aceitável, e desejável, que o port deixe arquivos modificados pelo usuário por fora do port) tem problemas em tempo de execução em sistemas nos quais é necessário que ele seja executado corretamente. A variável FORBIDDEN é usada para ports que contêm uma vulnerabilidade de segurança ou causam grande preocupação em relação à segurança de um sistema FreeBSD com um determinado port instalado (por exemplo, um programa de confiança inseguro ou um programa que fornece serviços facilmente exploráveis). Marcar ports como FORBIDDEN assim que um determinado software tiver uma vulnerabilidade e não houver atualização liberada. Idealmente, atualize os ports o mais rápido possível quando uma vulnerabilidade de segurança for descoberta para reduzir o número de hosts vulneráveis ​​do FreeBSD (gostamos de ser conhecidos pela segurança), mas às vezes há um intervalo de tempo entre a divulgação de uma vulnerabilidade e uma versão atualizada do software vulnerável. Não marque um port como FORBIDDEN por qualquer outro motivo que não seja segurança. A variável IGNORE é reservada para ports que não devem ser compilados por algum outro motivo. Use-a para ports em que o problema é considerado estrutural. O cluster de build não criará, sob nenhuma circunstância, ports marcados com a variável IGNORE. Por exemplo, use IGNORE quando um port: não funciona na versão instalada do FreeBSD tem um distfile que não pôde ser obtido automaticamente devido a restrições de licenciamento não funciona com algum outro port atualmente instalado (por exemplo, o port depende do www/apache20 mas www/apache22 está instalado) Se um port entrar em conflito com um port que está atualmente instalado (por exemplo, se eles instalam um arquivo no mesmo local que executa uma função diferente), use a variável CONFLICTS como uma alternativa. CONFLICTS ajustará IGNORE por si próprio. Notas de Implementação Não coloque os valores de BROKEN, IGNORE e variáveis ​​relacionadas entre aspas. Devido à forma como a informação é mostrada ao usuário, o texto das mensagens para cada variável é diferente: BROKEN= fails to link with base -lcrypto IGNORE= unsupported on recent versions resultando nesta saída a partir do comando make describe: ===> foobar-0.1 is marked as broken: fails to link with base -lcrypto. ===> foobar-0.1 is unsupported on recent versions. Considerações Arquitetônicas Marcando um Port como de Arquitetura Neutra Os ports que não possuem requisitos ou arquivos dependentes de arquitetura são identificados com NO_ARCH=yes. Marcando um port para ser ignorado apenas em determinadas arquiteturas Para marcar um port com IGNORE apenas em determinadas arquiteturas, existem duas outras variáveis ​​de conveniência que irão setar automaticamente IGNORE: ONLY_FOR_ARCHS e NOT_FOR_ARCHS. Exemplos: ONLY_FOR_ARCHS= i386 amd64 NOT_FOR_ARCHS= ia64 sparc64 Uma mensagem de IGNORE customizada pode ser definida usando as variáveis ONLY_FOR_ARCHS_REASON e NOT_FOR_ARCHS_REASON. É possível definir entradas por arquitetura com as variáveis ONLY_FOR_ARCHS_REASON_ARCH e NOT_FOR_ARCHS_REASON_ARCH. Se um port baixar e instalar binários i386, defina a variável IA32_BINARY_PORT. Se esta variável estiver definida,/usr/lib32 deve estar presente para versões IA32 de bibliotecas e o kernel deve suportar compatibilidade com IA32. Se uma dessas duas dependências não forem satisfeitas, IGNORE será definido automaticamente. Marcando um Port para Remoção com <varname>DEPRECATED</varname> ou <varname>EXPIRATION_DATE</varname> Lembre-se que BROKEN e FORBIDDEN devem ser usados ​​como um recurso temporário se um port não estiver funcionando. Ports permanentemente quebrados serão removidos da árvore por completo. Quando fizer sentido, os usuários podem ser avisados ​​sobre uma remoção de port pendente com as variáveis DEPRECATED e EXPIRATION_DATE. A primeira é uma string que indica porque o port está programado para remoção; a segunda é uma string no formato ISO 8601 (YYYY-MM-DD). Ambos serão mostrados ao usuário. É possível definir a variável DEPRECATED sem uma EXPIRATION_DATE (por exemplo, recomendando uma versão mais nova do port), mas o contrário não faz sentido. Não existe uma política definida sobre o tempo de aviso a ser dado. A prática atual parece ser de um mês para problemas relacionados à segurança e dois meses para problemas de compilação. Isso também dá a algum interessado um pouco de tempo para resolver os problemas. Evite o Uso do Construtor <literal>.error</literal> A maneira correta de um Makefile sinalizar que o port não pode ser instalado devido a algum fator externo (por exemplo, o usuário especificou uma combinação ilegal de opções de compilação) é definir um valor não vazio para IGNORE. Este valor será formatado e mostrado ao usuário pelo comando make install. É um equívoco comum usar .error para esse propósito. O problema com isso é que muitas ferramentas automatizadas que funcionam com a árvore de ports falharão nessa situação. A ocorrência mais comum disso é encontrada ao tentar construir o arquivo /usr/ports/INDEX (Veja ). No entanto, comandos ainda mais triviais, como make maintainer também irão falhar neste cenário. E Isto não é aceitável. Como Evitar o Uso de <literal>.error</literal> O primeiro dos próximos dois trechos de Makefile irá fazer o make index falhar, enquanto o segundo não: .error "option is not supported" IGNORE=option is not supported Uso de <filename>sysctl</filename> O uso de sysctl é desencorajado, exceto nos targets. Isso porque ele seria processado na execução de qualquer makevar, como os usados durante um make index, e assim teria que executar o comando, retardando ainda mais esse processo. Use apenas sysctl8 através de SYSCTL, pois contém o caminho completo e pode ser modificado, se alguém tiver uma necessidade especial. Atualizando Distfiles De vez em quando os autores de software alteram o conteúdo dos distfiles liberados sem alterar o nome do arquivo. Verifique se as alterações são oficiais e se foram realizadas pelo autor. Já aconteceu no passado em que o distfile foi silenciosamente alterado nos servidores de download com a intenção de prejudicar ou comprometer a segurança do usuário final. Coloque o antigo distfile de lado, faça o download do novo, descompacte-o e compare o conteúdo com o diff1. Se não houver nada suspeito, atualize o distinfo. Certifique-se de resumir as diferenças no log do PR e do commit, para que outras pessoas saibam que nada de ruim aconteceu. Contate os autores do software e confirme as alterações com eles. Uso de Padrões <acronym>POSIX</acronym> Os ports do FreeBSD geralmente esperam conformidade com POSIX. Alguns softwares e sistemas de compilação fazem suposições baseadas em um sistema operacional ou ambiente específico que pode causar problemas quando usado em um port. Não use /proc se houver outras maneiras de obter as informações. Por exemplo, setprogname(argv[0]) dentro de main() e depois getprogname3 para saber o nome do executável. Não confie em comportamento não documentado pelo POSIX. Não registre timestamps no caminho crítico do aplicativo se ele também funcionar sem. Obter registros de timestamps pode ser lento, dependendo da precisão dos registros de timestamp no SO. Se os timestamps forem realmente necessários, determine o quão precisos eles devem ser e use uma API documentada para fornecer a precisão necessária. Um número razoável de syscalls simples (por exemplo gettimeofday2, getpid2) são muito mais rápidos no Linux do que em qualquer outro sistema operacional, devido ao armazenamento em cache e às otimizações de desempenho do vsyscall. Não confie que seus custos sejam baratos em aplicativos de desempenho crítico. Em geral, tente evitar as syscalls se possível. Não confie no comportamento de sockets específicos do Linux. Em particular, os tamanhos padrão do buffer de socket são diferentes (chamadas setsockopt2 com SO_SNDBUF e SO_RCVBUF, e enquanto o send2 do Linux's bloqueia quando o buffer do socket está cheio, o do FreeBSD falhará e definirá ENOBUFS no errno). Se for necessário depender de um comportamento não padrão, encapsule-o adequadamente em uma API genérica, verifique o comportamento no estágio de configuração e pare se ele estiver ausente. Verifique as páginas de manual para ver se a função usada é uma interface POSIX (na seção STANDARDS da página de manual). Não assuma que /bin/sh é o bash. Certifique-se de que uma linha de comando passada para system3 irá funcionar com um shell compatível com POSIX. Uma lista de bashismos comum está disponível aqui. Verifique se os cabeçalhos estão incluídos no POSIX ou da maneira recomendada na página do manual. Por exemplo,sys/types.h é muitas vezes esquecido, o que não é tanto um problema para o Linux como é para o FreeBSD. Miscelânea Sempre verifique duas vezes os arquivos pkg-descr e pkg-plist. Se estiver revisando um port e uma melhor formulação puder ser alcançada, faça isso. Não faça mais cópias da Licença GNU General Public License em nosso sistema. Obrigado. Por favor, tenha cuidado ao notar quaisquer questões legais! Não nos deixe distribuir software ilegalmente! Um Exemplo de <filename>Makefile</filename> Aqui está um exemplo de Makefile que pode ser usado para criar um novo port. Certifique-se de remover todos os comentários extras (entre colchetes). O formato apresentado é o recomendado para ordenar variáveis, linhas vazias entre seções e assim por diante. Esse formato é projetado para que as informações mais importantes sejam fáceis de serem localizadas. Recomendamos usar o portlint para verificar o Makefile. [the header...just to make it easier for us to identify the ports.] # $FreeBSD$ [ ^^^^^^^^^ This will be automatically replaced with RCS ID string by SVN when it is committed to our repository. If upgrading a port, do not alter this line back to "$FreeBSD$". SVN deals with it automatically.] [section to describe the port itself and the master site - PORTNAME and PORTVERSION or the DISTVERSION* variables are always first, followed by CATEGORIES, and then MASTER_SITES, which can be followed by MASTER_SITE_SUBDIR. PKGNAMEPREFIX and PKGNAMESUFFIX, if needed, will be after that. Then comes DISTNAME, EXTRACT_SUFX and/or DISTFILES, and then EXTRACT_ONLY, as necessary.] PORTNAME= xdvi DISTVERSION= 18.2 CATEGORIES= print [do not forget the trailing slash ("/")! if not using MASTER_SITE_* macros] MASTER_SITES= ${MASTER_SITE_XCONTRIB} MASTER_SITE_SUBDIR= applications PKGNAMEPREFIX= ja- DISTNAME= xdvi-pl18 [set this if the source is not in the standard ".tar.gz" form] EXTRACT_SUFX= .tar.Z [section for distributed patches -- can be empty] PATCH_SITES= ftp://ftp.sra.co.jp/pub/X11/japanese/ PATCHFILES= xdvi-18.patch1.gz xdvi-18.patch2.gz [If the distributed patches were not made relative to ${WRKSRC}, this may need to be tweaked] PATCH_DIST_STRIP= -p1 [maintainer; *mandatory*! This is the person who is volunteering to handle port updates, build breakages, and to whom a users can direct questions and bug reports. To keep the quality of the Ports Collection as high as possible, we do not accept new ports that are assigned to "ports@FreeBSD.org".] MAINTAINER= asami@FreeBSD.org COMMENT= DVI Previewer for the X Window System [license -- should not be empty] LICENSE= BSD2CLAUSE LICENSE_FILE= ${WRKSRC}/LICENSE [dependencies -- can be empty] RUN_DEPENDS= gs:print/ghostscript [If it requires GNU make, not /usr/bin/make, to build...] USES= gmake [If it is an X application and requires "xmkmf -a" to be run...] USES= imake [If the source is obtained from github, remove MASTER_SITE* and...] USE_GITHUB= yes GH_ACCOUNT= example [this section is for other standard bsd.port.mk variables that do not] belong to any of the above] [If it asks questions during configure, build, install...] IS_INTERACTIVE= yes [If it extracts to a directory other than ${DISTNAME}...] WRKSRC= ${WRKDIR}/xdvi-new [If it requires a "configure" script generated by GNU autoconf to be run] GNU_CONFIGURE= yes [et cetera.] [If it requires options, this section is for options] OPTIONS_DEFINE= DOCS EXAMPLES FOO OPTIONS_DEFAULT= FOO [If options will change the files in plist] OPTIONS_SUB=yes FOO_DESC= Enable foo support FOO_CONFIGURE_ENABLE= foo [non-standard variables to be used in the rules below] MY_FAVORITE_RESPONSE= "yeah, right" [then the special rules, in the order they are called] pre-fetch: i go fetch something, yeah post-patch: i need to do something after patch, great pre-install: and then some more stuff before installing, wow [and then the epilogue] .include <bsd.port.mk> Ordem das Variáveis ​​nos Makefiles de Port As primeiras seções do Makefile devem sempre vir na mesma ordem. Este padrão faz com que todos possam ler facilmente qualquer port sem ter que procurar variáveis ​​em uma ordem aleatória. A primeira linha de um Makefile é sempre um comentário contendo o ID de controle de versão do Subversion, seguido por uma linha vazia. Em novos ports, parece assim: # $FreeBSD$   Nos ports existentes, o Subversion expandiu essa entrada ficando assim: # $FreeBSD$   As seções e variáveis ​​descritas aqui são obrigatórias em um port comum. Em um port slave, muitas seções ​​e variáveis podem ser ignoradas. Cada bloco seguinte deve ser separado do bloco anterior por uma única linha em branco. Nos blocos a seguir, apenas defina as variáveis ​​que são requeridas pelo port. Defina essas variáveis ​​na ordem em que são mostradas aqui. Bloco <varname>PORTNAME</varname> Este bloco é o mais importante. Ele define o nome do port, a versão, o local do arquivo de distribuição e a categoria. As variáveis ​​devem estar nesta ordem: PORTNAME PORTVERSION DISTVERSIONPREFIX DISTVERSION DISTVERSIONSUFFIX PORTREVISION PORTEPOCH CATEGORIES MASTER_SITES MASTER_SITE_SUBDIR (descontinuado) PKGNAMEPREFIX PKGNAMESUFFIX DISTNAME EXTRACT_SUFX DISTFILES DIST_SUBDIR EXTRACT_ONLY Apenas uma das variáveis PORTVERSION e DISTVERSION podem ser usadas. Bloco <varname>PATCHFILES</varname> Este bloco é opcional. As variáveis ​​são: PATCH_SITES PATCHFILES PATCH_DIST_STRIP Bloco <varname>MAINTAINER</varname> Este bloco é obrigatório. As variáveis ​​são: MAINTAINER COMMENT Bloco <varname>LICENSE</varname> Este bloco é opcional, embora seja altamente recomendado. As variáveis ​​são: LICENSE LICENSE_COMB LICENSE_GROUPS ou LICENSE_GROUPS_NOME LICENSE_NAME ou LICENSE_NAME_NOME LICENSE_TEXT ou LICENSE_TEXT_NOME LICENSE_FILE ou LICENSE_FILE_NOME LICENSE_PERMS ou LICENSE_PERMS_NOME LICENSE_DISTFILES ou LICENSE_DISTFILES_NOME Se houver várias licenças, ordene as variáveis LICENSE_VAR_NOME pelo nome de licença. Mensagens Genéricas <varname>BROKEN</varname>/<varname>IGNORE</varname>/<varname>DEPRECATED</varname> Este bloco é opcional. As variáveis ​​são: DEPRECATED EXPIRATION_DATE FORBIDDEN BROKEN BROKEN_* IGNORE IGNORE_* ONLY_FOR_ARCHS ONLY_FOR_ARCHS_REASON* NOT_FOR_ARCHS NOT_FOR_ARCHS_REASON* BROKEN_* e IGNORE_* podem ser qualquer variável genérica, por exemplo, IGNORE_amd64, BROKEN_FreeBSD_10, etc. Com exceção das variáveis ​​que dependem de uma variável USES, coloque essas em . Por exemplo, IGNORE_WITH_PHP só funciona se USES=php estiver definido e a variável BROKEN_SSL somente se USES=ssl estiver definido. Se o port estiver marcado como BROKEN quando algumas condições forem atendidas, e tais condições puderem ser testadas somente após incluir o bsd.port.options.mk ou bsd.port.pre.mk, então essas variáveis ​​devem ser definidas mais tarde, em . O Bloco de Dependências Este bloco é opcional. As variáveis ​​são: FETCH_DEPENDS EXTRACT_DEPENDS PATCH_DEPENDS BUILD_DEPENDS LIB_DEPENDS RUN_DEPENDS TEST_DEPENDS Flavors Este bloco é opcional. Comece esta seção com as definições de FLAVORS. Continue com as possíveis variáveis assistentes de Flavors. Veja para maiores informações. Variáveis ​​de definição de construção não disponíveis como assistentes, usando .if ${FLAVOR:U} == foo devem ir em abaixo de suas respectivas seções. <varname>USES</varname> e <varname>USE_<replaceable>x</replaceable></varname> Comece esta seção com a definição da variável USES e, em seguida, possíveis variáveis USE_x. Mantenha as variáveis ​​relacionadas juntas. Por exemplo, se estiver usando a variável USE_GITHUB, coloque sempre as variáveis GH_* ​​logo após ela. Variáveis ​​Padrão <filename>bsd.port.mk</filename> Este bloco de seção é para variáveis ​​que podem ser definidas em bsd.port.mk que não pertencem a nenhum dos blocos de seção anteriores. A ordem não é importante, no entanto, tente manter variáveis ​​semelhantes juntas. Por exemplo, variáveis ​​USERS e GROUPS. Variáveis ​​de configuração CONFIGURE_* e *_CONFIGURE. Lista de arquivos e diretórios PORTDOCS e PORTEXAMPLES. Opções e Assistentes Se o port usa o framework de opções, defina OPTIONS_DEFINE e OPTIONS_DEFAULT, então as outras variáveis OPTIONS_*, depois as de descrições *_DESC, e então os assistentes de opções. Tente e ordene todas essas variáveis alfabeticamente. Exemplo de Ordenamento das Variáveis ​​de Opções As opções FOO e BAR não possuem uma descrição padrão, portanto, é necessário escrever uma. As outras opções já possuem em Mk/bsd.options.desc.mk então escrever uma não é necessário. Opções DOCS e EXAMPLES usam os assistentes de destino para instalar seus arquivos, eles são mostrados aqui por completo, apesar de pertencerem a , então outras variáveis ​​e destinos podem ser inseridos antes deles. OPTIONS_DEFINE= DOCS EXAMPLES FOO BAR OPTIONS_DEFAULT= FOO OPTIONS_RADIO= SSL OPTIONS_RADIO_SSL= OPENSSL GNUTLS OPTIONS_SUB= yes BAR_DESC= Enable bar support FOO_DESC= Enable foo support BAR_CONFIGURE_WITH= bar=${LOCALBASE} FOO_CONFIGURE_ENABLE= foo GNUTLS_CONFIGURE_ON= --with-ssl=gnutls OPENSSL_CONFIGURE_ON= --with-ssl=openssl post-install-DOCS-on: ${MKDIR} ${STAGEDIR}${DOCSDIR} cd ${WRKSRC}/doc && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} post-install-EXAMPLES-on: ${MKDIR} ${STAGEDIR}${EXAMPLESDIR} cd ${WRKSRC}/ex && ${COPYTREE_SHARE} . ${STAGEDIR}${DOCSDIR} O Restante das Variáveis E então, o restante das variáveis ​​que não são mencionadas nos blocos anteriores. Os Targets Depois que todas as variáveis ​​são definidas, targets opcionais make1 podem ser definidos. Mantenha pre-* antes de post-* e na mesma ordem em que as diferentes etapas são executadas: fetch extract patch configure build install test Ao usar os assistentes de opções, os targets são classificados alfabeticamente, mas mantenha *-on antes do *-off. Quando também estiver usando o target principal, mantenha o target principal antes dos opcionais: post-install: # install generic bits post-install-DOCS-on: # Install documentation post-install-X11-on: # Install X11 related bits post-install-X11-off: # Install bits that should be there if X11 is disabled Mantendo-se Atualizado A coleção de Ports do FreeBSD está em constante mudança. Aqui estão algumas informações sobre como se manter atualizado. FreshPorts Uma das maneiras mais fáceis de saber sobre atualizações que já foram submetidas é assinando o FreshPorts. Múltiplos ports podem ser monitoradas. Os mantenedores são fortemente encorajados a se inscrever, porque eles receberão uma notificação não apenas de suas próprias mudanças, mas também de quaisquer mudanças que qualquer outro committer do FreeBSD tenha feito. (Geralmente é necessário para acompanhar as mudanças na estrutura de ports subjacentes - embora seja mais educado receber um aviso antecipado daqueles que submeterem essas mudanças, às vezes isso é negligenciado ou impraticável. Além disso, em alguns casos, as alterações são muito menores por natureza. Esperamos que todos usem seu melhor julgamento nesses casos.) Para usar o FreshPorts, é necessário uma conta. Aqueles com endereços de email registrados @FreeBSD.org verão um link opt-in no lado direito das páginas web. Aqueles que já possuem uma conta no FreshPorts, mas não estão usando endereço de email @FreeBSD.org podem alterar o e-mail para @FreeBSD.org, se inscrever, e então alterar o email novamente. O FreshPorts também possui um recurso de teste de sanidade que testa automaticamente cada commit na árvore de ports do FreeBSD. Se inscrito neste serviço, um committer receberá notificações de quaisquer erros que o FreshPorts detectar durante o teste de sanidade de seus commits. A interface Web para o Repositório do Código Fonte É possível visualizar os arquivos no repositório de código fonte usando uma interface web. As alterações que afetam todo o sistema de ports agora são documentadas no arquivo CHANGES. As alterações que afetam os ports individuais agora são documentadas no arquivo UPDATING. No entanto, a resposta definitiva a qualquer questão é, sem dúvida, ler o código fonte do arquivo bsd.port.mk e arquivos associados. A Lista de Discussão de Ports do FreeBSD Como um mantenedor de ports, considere assinar a lista de discussão de ports do FreeBSD. Mudanças importantes na maneira como os ports funcionam serão anunciadas nela e depois serão inseridas no arquivo CHANGES. Se o volume de mensagens nesta lista de discussão for muito alto, considere seguir a lista de anúncios de ports do FreeBSD que contém apenas os anúncios. O Cluster de Compilação de Ports do FreeBSD Um dos pontos fortes menos divulgados do FreeBSD é que um cluster inteiro de máquinas é dedicado na compilação continua da Coleção de Ports, para cada um dos principais releases do SO e para cada arquitetura Tier-1. Ports individuais são compilados a menos que sejam especificamente marcados com IGNORE. Ports marcados com BROKEN ainda sofrem tentativas de compilação, para verificarem se o problema foi resolvido. (Isso é feito passando TRYBROKEN para o Makefile do port.) Portscout: o Scanner de Distfile de Ports do FreeBSD O cluster de compilação é dedicado na compilação da última versão de cada port com os distfiles que já foram baixados. No entanto, como a Internet muda continuamente, os distfiles podem desaparecer rapidamente. Portscout, o scanner de distfile de Ports do FreeBSD, tenta consultar cada site de download para cada port e assim descobrir se cada distfile ainda está disponível.Portscout pode gerar relatórios em HTML e enviar emails sobre novos ports disponíveis para aqueles que os solicitam. A menos que não seja assinado de outra forma, os mantenedores são solicitados a verificar periodicamente as mudanças, seja manualmente ou usando o feed RSS. A primeira página do Portscout fornece o endereço de e-mail do mantenedor de port, o número de ports pelos quais o mantenedor é responsável, o número desses ports com novos distfiles e a porcentagem dos ports que estão desatualizados. A função de pesquisa permite pesquisar por endereço de email de um mantenedor específico e permite também selecionar se apenas os ports desatualizados serão mostrados. Ao clicar no endereço de email de um mantenedor, uma lista de todos os seus ports é exibida, junto com a categoria do port, o número da versão atual, se há ou não uma nova versão, quando o port foi atualizado e finalmente quando foi sua última checagem. Uma função de pesquisa nesta página permite que o usuário pesquise por um port específico. Clicar em um nome de port na lista exibe as informações FreshPorts do port. O Sistema de Monitoramento de Ports do FreeBSD Outro recurso útil é o Sistema de Monitoramento de Ports do FreeBSD (também conhecido como portsmon). Este sistema compreende em um banco de dados que processa informações de várias fontes e permite que ele seja acessado através de uma interface web. Atualmente, os Relatórios de Problemas (PRs) dos ports, os logs de erros do cluster de compilação e os arquivos individuais da coleção de ports são usados. No futuro, isso será expandido para incluir pesquisa de distfile, bem como outras fontes. Para começar, use a página de busca Overview of One Port para encontrar todas as informações sobre um port. Este é o único recurso disponível que mapeia entradas de PR para nomes de ports. Os remetentes de PR nem sempre incluem o nome do port em sua Sinopse, embora preferiríamos que eles o fizessem. Logo, portsmon é um bom lugar para descobrir se um port existente tem algum PR arquivado, qualquer erro de compilação ou se um novo port que o mantenedor está considerando criar já foi submetido. Usando Macros <varname>USES</varname> Uma introdução ao <varname>USES</varname> As macros USES facilitam declarar requisitos e configurações de um port. Elas podem adicionar dependências, alterar o comportamento de compilação do port, adicionar metadados a pacotes e assim por diante, tudo selecionando valores simples e predefinidos. Cada seção deste capítulo descreve um possível valor para USES, juntamente com seus possíveis argumentos. Argumentos são anexados ao valor após dois pontos (:). Vários argumentos são separados por vírgulas (,). Usando Vários Valores USES= bison perl Adicionando um Argumento USES= gmake:lite Adicionando Vários Argumentos USES= drupal:7,theme Entrelaçando Tudo Isso Junto USES= pgsql:9.3+ cpe python:2.7,build <literal>7z</literal> Argumentos possíveis: (none), p7zip, partial Extrair usando 7z1 ao invés de bsdtar1 e definir EXTRACT_SUFX=.7z. A opção p7zip força uma dependência do 7z a partir de archivers/p7zip se aquele do sistema base não for capaz de extrair os arquivos. EXTRACT_SUFX não é alterado se a opção partial é usada, isso pode ser usado se o arquivo de distribuição principal não tiver extensão .7z. <literal>ada</literal> Argumentos possíveis: (none), 5, 6 Depende de um compilador capaz de usar Ada e define a variável CC de acordo. O padrão é usar gcc 5 do ports. Use a opção de versão :X para forçar a compilação com uma versão diferente. <literal>autoreconf</literal> Argumentos possíveis: (none), build Execute autoreconf. Ele encapsula os comandos aclocal, autoconf, autoheader, automake, autopoint e libtoolize. Cada comando aplica-se a ${AUTORECONF_WRKSRC} /configure.ac ou seu nome antigo ${AUTORECONF_WRKSRC}/configure.in. E se configure.ac define subdiretórios com seus próprios configure.ac usando AC_CONFIG_SUBDIRS, autoreconf irá recursivamente atualizar aqueles também. O argumento :build só adiciona dependências de build-time sobre essas ferramentas, mas não executa o autoreconf. Um port pode definir AUTORECONF_WRKSRC se WRKSRC não contiver o caminho para o configure.ac. <literal>blaslapack</literal> Argumentos possíveis: (none), atlas, netlib(padrão), gotoblas, openblas Adiciona dependências das bibliotecas Blas / Lapack. <literal>bdb</literal> Argumentos possíveis: (none), 48, 5(padrão), 6 Adiciona uma dependência à biblioteca Berkeley DB. O padrão utiliza databases/db5. Também pode depender de databases/db48 ao usar o argumento :48 ou databases/db6 com :6. É possível declarar um intervalo de valores aceitáveis, :48+ procura pela versão maior instalada e utiliza a 4.8 se nenhuma outra estiver instalada. INVALID_BDB_VER pode ser usado para especificar versões que não funcionam com este port. O framework expõe as seguintes variáveis ao port: BDB_LIB_NAME O nome da biblioteca Berkeley DB. Por exemplo, ao usar databases/db5, contém db-5.3. BDB_LIB_CXX_NAME O nome da biblioteca Berkeley DB C++. Por exemplo, ao usar databases/db5, contém db_cxx-5.3. BDB_INCLUDE_DIR A localização do diretório incluso Berkeley DB. Por exemplo, ao usar databases/db5, ele irá conter ${LOCALBASE}/include/db5. BDB_LIB_DIR A localização do diretório da biblioteca Berkeley DB. Por exemplo, ao usar databases/db5, contém ${LOCALBASE}/lib. BDB_VER A versão detectada de Berkeley DB. Por exemplo, se estiver usando USES=bdb:48+ e Berkeley DB 5 estiver instalado, irá conter 5. databases/db48 está obsoleto e não é suportado. Não deve ser usado por nenhum port. <literal>bison</literal> Argumentos possíveis: (none), build, run, both Utiliza devel/bison por padrão, sem argumentos ou com o argumento build, isso implica que bison seja uma dependência de build-time, run implica como dependência de run-time e both implica em dependências build-time e run-time. <literal>cargo</literal> Argumentos possíveis: (none) Utiliza Cargo para configuração, compilação e testes. Ele pode ser usado para portar aplicativos Rust que usam o sistema de build Cargo. Para obter mais informações, consulte . <literal>charsetfix</literal> Argumentos possíveis: (none) Previne que o port instale arquivos charset.alias. Estes arquivos devem ser instalados apenas pelo converters/libiconv. CHARSETFIX_MAKEFILEIN pode ser definido para um caminho relativo ao WRKSRC se charset.alias não for instalado pelo ${WRKSRC}/Makefile.in. <literal>cmake</literal> Argumentos possíveis: (none), env, notall, noman Utiliza QMake para configuração e compilação. Por padrão, uma compilação out-of-source é executada, deixando os fontes em WRKSRC livres de artefatos de compilação. Com o argumento insource, uma compilação in-source será executada. A configuração deste argumento deve ser a exceção quando uma compilação regular out-of-source não funcionar. Por padrão, o argumento Ninja é usado para a compilação. Em alguns casos isso não funciona corretamente. Com o argumento noninja, a compilação irá usar o make para as compilações. Ele só deve ser usado se uma compilação baseada no Ninja não funcionar. Com o argumento run, uma dependência de execução é registrada além de uma dependência de compilação. Para maiores informações, veja . <literal>compiler</literal> Argumentos possíveis: (none), env (padrão, implícito) c++17-lang, c++14-lang, c++11-lang, gcc-c++11-lib, c++11-lib, c++0x, c11, openmp, nestedfct, features Determina qual compilador usar com base em qualquer um desejo. Use c++17-lang se o port precisar de um compilador compatível com C++17, c++14-lang se o port precisar de um compilador compatível com C++14, c++11-lang se o port precisar de um compilador compatível com C++11, gcc-c++11-lib se o port precisar do compilador g++ com uma biblioteca C++11, ou c++11-lib se o port precisar de uma biblioteca padrão C++11-ready. Se o port precisar de um compilador que compreenda as funções C++0X, C11, OpenMP ou funções aninhadas, os parâmetros correspondentes deverão ser usados. Use features para solicitar uma lista de recursos suportados pelo compilador padrão. Depois de incluir o arquivo bsd.port.pre.mk o port pode inspecionar os resultados usando estas variáveis: COMPILER_TYPE: o compilador padrão no sistema, gcc ou clang ALT_COMPILER_TYPE: o compilador alternativo no sistema, gcc ou clang. Apenas definido se dois compiladores estiverem presentes na base do sistema. COMPILER_VERSION: os dois primeiros dígitos da versão do compilador padrão. ALT_COMPILER_VERSION: os dois primeiros dígitos da versão do compilador alternativo, se presente. CHOSEN_COMPILER_TYPE: o compilador escolhido, gcc ou clang COMPILER_FEATURES: os recursos suportados pelo compilador padrão. Atualmente lista a biblioteca C++. <literal>cpe</literal> Argumentos possíveis: (none) Inclui informações da Common Platform Enumeration (CPE) no manifesto do pacote como uma string CPE 2.3 formatada. Veja as especificações CPE para mais detalhes. Para adicionar informações de CPE a um port, siga estas etapas: Procure pelo registro oficial CPE para o produto de software, usando o mecanismo de pesquisa CPE do NVD ou no dicionário oficial CPE (aviso, o arquivo XML é muito grande). Nunca crie os dados da CPE. Adicione cpe na variável USES e compare o resultado de make -V CPE_STR com o registro no dicionário CPE. Continue com um passo de cada vez até make -V CPE_STR ficar correto. Se o nome do produto (segundo campo, com o valor padrão para PORTNAME) estiver incorreto, defina CPE_PRODUCT. Se o nome do fornecedor (primeiro campo, com o valor padrão para CPE_PRODUCT) estiver incorreto, defina CPE_VENDOR. Se o campo de versão (terceiro campo, com o valor padrão para PORTVERSION) estiver incorreto, defina CPE_VERSION. Se o campo de atualização (quarto campo, valor padrão vazio) estiver incorreto, defina CPE_UPDATE. Se ainda não estiver correto, verifique o arquivo Mk/Uses/cpe.mk para detalhes adicionais, ou entre em contato com o Ports Security Team ports-secteam@FreeBSD.org. Derive o máximo possível do nome CPE a partir de variáveis ​​existentes, tal como as variáveis PORTNAME e PORTVERSION. Use modificadores de variáveis ​​para extrair as partes relevantes delas, em vez de colocar o nome direto no código. Sempre execute make -V CPE_STR e verifique a saída antes de fazer o commit de qualquer coisa que mude o PORTNAME ou PORTVERSION ou qualquer outra variável que é usada para derivar a variável CPE_STR. <literal>cran</literal> Argumentos possíveis: (none), auto-plist, compiles Utiliza a Comprehensive R Archive Network. Especifique auto-plist para gerar automaticamente o arquivo pkg-plist. Especifique compiles se o port tiver código que precise ser compilado. <literal>desktop-file-utils</literal> Argumentos possíveis: (none) Utiliza update-desktop-database a partir de devel/desktop-file-utils. Uma etapa extra de post-install será executada sem interferir em nenhuma etapa de post-install que já esteja no Makefile do port. Uma linha com @desktop-file-utils será adicionada ao plist. <literal>desthack</literal> Argumentos possíveis: (none) Altera o comportamento do GNU configure para suportar corretamente a variável DESTDIR no caso do software original não suportar. <literal>display</literal> Argumentos possíveis: (none), ARGS Define um display environment virtual. Se a variável de ambiente DISPLAY não estiver definida, então Xvfb é adicionado como uma dependência de compilação e a variável CONFIGURE_ENV é estendida com o número do port da instância do Xvfb em execução no momento. O parâmetro ARGS é definido como install por padrão e controla a fase na qual se inicia e para a exibição virtual. <literal>dos2unix</literal> Argumentos possíveis: (none) O port tem arquivos com terminações de linha no formato do DOS que precisam ser convertidos. Inúmeras variáveis ​​podem ser definidas para controlar quais arquivos serão convertidos. O padrão é converter todos arquivos, incluindo binários. Veja para exemplos. DOS2UNIX_REGEX: casa nomes de arquivos com base em uma expressão regular. DOS2UNIX_FILES: casa com nomes de arquivos literais. DOS2UNIX_GLOB: casa com nomes de arquivos baseados em um padrão glob. DOS2UNX_WRKSRC: o diretório onde iniciar as conversões. O padrão é ${WRKSRC}. <literal>drupal</literal> Argumentos possíveis: 7, module, theme Automatiza a instalação de um port que é um tema ou módulo Drupal. Use com a versão Drupal que o port está esperando. Por exemplo, USES=drupal:7,module diz que este port cria um módulo do Drupal 6. Um tema do Drupal 7 pode ser especificado com USES=drupal:7,theme. <literal>fakeroot</literal> Argumentos possíveis: (none) Altera alguns comportamentos padrão dos sistemas de compilação para permitir instalar como um usuário normal. Veja para mais informações sobre fakeroot. <literal>fam</literal> Argumentos possíveis: (none), fam, gamin Usa um File Alteration Monitor como uma dependência de biblioteca, devel/fam ou devel/gamin. Usuários finais podem definir WITH_FAM_SYSTEM para especificar sua preferência. <literal>firebird</literal> Argumentos possíveis: (none), 25 Adiciona uma dependência da biblioteca client do banco de dados do Firebird. <literal>fonts</literal> Argumentos possíveis: (none), fc, fcfontsdir(padrão), fontsdir, none Adiciona uma dependência de tempo de execução nas ferramentas necessárias para registrar fontes. Dependendo do argumento, adiciona entradas para o plist @fc ${FONTSDIR}, @fcfontsdir ${FONTSDIR}, @fontsdir ${FONTSDIR}, ou nenhuma entrada se o argumento for none. Valor padrão de FONTSDIR é ${PREFIX}/share/fonts/${FONTNAME} e FONTNAME é ${PORTNAME}. Adiciona FONTSDIR para PLIST_SUB e SUB_LIST. <literal>fortran</literal> Argumentos possíveis: gcc (padrão) Usa o compilador GNU Fortran. <literal>fuse</literal> Argumentos possíveis: 2 (padrão), 3 O port irá depender da biblioteca FUSE e irá manipular a dependência do módulo do kernel dependendo da versão do FreeBSD. - - <literal>gecko</literal> - - Argumentos possíveis: libxul (padrão), firefox, seamonkey, thunderbird, build, XY, XY+ - - Adiciona uma dependência de diferentes aplicações baseadas em libxul. Se libxul for usado, é o único argumento permitido. Quando o argumento não for libxul, os argumentos do firefox, seamonkey ou thunderbird podem ser usados, juntamente com argumentos opcionais build e XY/XY+. - - <literal>gem</literal> Argumentos possíveis: (none), noautoplist Manipula a compilação com RubyGems. Se noautoplist for usado, a lista de empacotameno não será gerada automaticamente. <literal>gettext</literal> Argumentos possíveis: (none) Descontinuado. Incluirá ambos gettext-runtime e gettext-tools. <literal>gettext-runtime</literal> Argumentos possíveis: (none), lib (padrão),build, run Utiliza devel/gettext-runtime. Por padrão, sem argumentos ou com o argumento lib, implica uma dependência da biblioteca libintl.so. build e run implicam, respectivamente, uma dependência de gettext em build-time e run-time. <literal>gettext-tools</literal> Argumentos possíveis: (none), build (padrão),run Utiliza devel/gettext-tools. Por padrão, sem argumento ou com o argumento build, uma dependência de msgfmt em build-time é registrada. Com o argumento run, uma dependência em run-time é registrada. <literal>ghostscript</literal> Argumentos possíveis: X, build, run, nox11 Uma versão X específica pode ser usada. Versões possíveis são 7, 8, 9 e agpl (padrão). nox11 indica que a versão -nox11 do port é necessária. build e run adicionam dependências de Ghostscript em build-time e run-time. O padrão é ambas as dependências, build-time e run-time. <literal>gl</literal> Argumentos possíveis: (none) Fornece uma maneira fácil para depender dos componentes GL. Os componentes devem ser listados na variável USE_GL. Os componentes disponíveis são: egl adiciona uma dependência de biblioteca libEGL.so de graphics/mesa-libs gbm Adiciona uma dependência de biblioteca libgbm.so de graphics/mesa-libs gl Adiciona uma dependência de biblioteca libGL.so de graphics/mesa-libs glesv2 Adiciona uma dependência de biblioteca libGLESv2.so de graphics/mesa-libs glew Adiciona uma dependência de biblioteca libGLEW.so de graphics/glew glu Adiciona uma dependência de biblioteca libGLU.so de graphics/libGLU glut Adiciona uma dependência de biblioteca libglut.so de graphics/freeglut glw Adiciona uma dependência de biblioteca libGLw.so de graphics/libGLw <literal>gmake</literal> Argumentos possíveis: (none) Utiliza devel/gmake como uma dependência em run-time e configura o ambiente para usar gmake como make padrão para a compilação. <literal>gnome</literal> Argumentos possíveis: (none) Fornece uma maneira fácil para depender dos componentes do GNOME. Os componentes devem ser listados na variável USE_GNOME. Os componentes disponíveis são: atk atkmm cairo cairomm dconf esound evolutiondataserver3 gconf2 gconfmm26 gdkpixbuf gdkpixbuf2 glib12 glib20 glibmm gnomecontrolcenter3 gnomedesktop3 gnomedocutils gnomemenus3 gnomemimedata gnomeprefix gnomesharp20 gnomevfs2 gsound gtk-update-icon-cache gtk12 gtk20 gtk30 gtkhtml3 gtkhtml4 gtkmm20 gtkmm24 gtkmm30 gtksharp20 gtksourceview gtksourceview2 gtksourceview3 gtksourceviewmm3 gvfs intlhack intltool introspection libartlgpl2 libbonobo libbonoboui libgda5 libgda5-ui libgdamm5 libglade2 libgnome libgnomecanvas libgnomekbd libgnomeprint libgnomeprintui libgnomeui libgsf libgtkhtml libgtksourceviewmm libidl librsvg2 libsigc++12 libsigc++20 libwnck libwnck3 libxml++26 libxml2 libxslt metacity nautilus3 orbit2 pango pangomm pangox-compat py3gobject3 pygnome2 pygobject pygobject3 pygtk2 pygtksourceview referencehack vte vte3 A dependência padrão é em built-time e run-time, pode ser alterada com :build ou :run. Por exemplo: USES= gnome USE_GNOME= gnomemenus3:build intlhack Veja para maiores informações. <literal>go</literal> Ports não devem ser criados po bibliotecas Go, veja para maiores informações. - Argumentos possíveis: (none) + Argumentos possíveis: (none), modules - Define valores e targets padrão usados ​​para compilar aplicações Go. Uma dependência lang/go em build-time é adicionada. O processo de compilação é controlado por inumeras variáveis: + Define valores e targets padrão usados ​​para compilar aplicações Go. Uma dependência lang/go em build-time é adicionada. Por padrão, a compilação é executada no modo GOPATH. Se o software Go usa módulos, o modo de reconhecimento de módulos pode ser ativado com modules. + O processo de compilação é controlado por várias variáveis: + GO_PKGNAME - O nome do pacote Go. Este é o diretório que será criado em GOPATH/src. O valor padrão é o da variável ${PORTNAME}. + O nome do pacote Go. Ao compilar no modo GOPATH, este é o diretório que será criado em ${GOPATH}/src e visto pelo go. Ao compilar no modo de reconhecimento de módulos, nenhum diretório GOPATH será criado e o valor GO_PKGNAME será usado apenas como padrão para GO_TARGET. Se não estiver definido explicitamente e GH_SUBDIR estiver presente, o valor GO_PKGNAME será inferido de ${GH_SUBDIR}, caso contrário, será definido como ${PORTNAME}. GO_TARGET O nome dos pacotes a serem compilados. O valor padrão é o valor da variável ${GO_PKGNAME}. CGO_CFLAGS Valores adicionais da variável CFLAGS a serem passados ​​para o compilador C pelo Go. CGO_LDFLAGS Valores adicionais da variável LDFLAGS a serem passados ​​para o compilador C pelo Go. + + + GO_BUILDFLAGS + + + Argumentos de compilação adicionais para passar para o go install. + + <literal>gperf</literal> Argumentos possíveis: (none) Adiciona uma dependência devel/gperf em buildtime se gperf não estiver presente no sistema base. <literal>grantlee</literal> Argumentos possíveis: 5, selfbuild Manipula a dependência em Grantlee. Especifique 5 para depender da versão baseada no Qt5, devel/grantlee5. selfbuild é usado internamente pelo devel/grantlee5 para obter os números de suas versões. <literal>groff</literal> Argumentos possíveis: build, run, both Registra uma dependência de textproc/groff se não estiver presente no sistema base. <literal>gssapi</literal> Argumentos possíveis: (none), base (padrão), heimdal, mit, flags, bootstrap Manipular as dependências necessárias para os consumers do GSS-API. Apenas as bibliotecas que fornecem os mecanismos do Kerberos estão disponíveis. Por padrão, ou definido como base, a biblioteca GSS-API do sistema base é usada. Também pode ser definido para heimdal para usar security/heimdal ou mit para usar security/krb5. Quando a instalação local do Kerberos não está em LOCALBASE defina a variável HEIMDAL_HOME (para heimdal) ou a variável KRB5_HOME (para krb5) para a instalação local do Kerberos. Essas variáveis ​​são exportadas para os ports para serem usadas: GSSAPIBASEDIR GSSAPICPPFLAGS GSSAPIINCDIR GSSAPILDFLAGS GSSAPILIBDIR GSSAPILIBS GSSAPI_CONFIGURE_ARGS As opções de flags podem estar lado a lado com base, heimdal ou mit para adicionar automaticamente GSSAPICPPFLAGS, GSSAPILDFLAGS e GSSAPILIBS para CFLAGS, LDFLAGS e LDADD, respectivamente. Por exemplo, use base,flags. A opção bootstrap é um prefixo especial apenas para o uso do security/krb5 e security/heimdal. Por exemplo, use bootstrap,mit. Uso Típico OPTIONS_SINGLE= GSSAPI OPTIONS_SINGLE_GSSAPI= GSSAPI_BASE GSSAPI_HEIMDAL GSSAPI_MIT GSSAPI_NONE GSSAPI_BASE_USES= gssapi GSSAPI_BASE_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS} GSSAPI_HEIMDAL_USES= gssapi:heimdal GSSAPI_HEIMDAL_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS} GSSAPI_MIT_USES= gssapi:mit GSSAPI_MIT_CONFIGURE_ON= --with-gssapi=${GSSAPIBASEDIR} ${GSSAPI_CONFIGURE_ARGS} GSSAPI_NONE_CONFIGURE_ON= --without-gssapi <literal>horde</literal> Argumentos possíveis: (none) Adicionar dependências de builtime e runtime em devel/pear-channel-horde. Outras dependências Horde podem ser adicionadas com USE_HORDE_BUILD e USE_HORDE_RUN. Veja para maiores informações. <literal>iconv</literal> Argumentos possíveis: (none), lib, build, patch, translit, wchar_t Utilização de funções iconv, seja do port converters/libiconv como uma dependência de buil-time e run-time, ou do sistema base em um 10-CURRENT após um iconv nativo ser comitado em 254273. Por padrão, sem argumentos ou com o argumento lib, implica em iconv com dependências de build-time e run-time. build implica uma dependência de build-time e patch implica uma dependência de patch-time. Se o port usa extensões iconv WCHAR_T ou //TRANSLIT , adicione os argumentos relevantes para que o iconv correto seja usado. Para mais informações, veja . <literal>imake</literal> Argumentos possíveis: (none), env, notall, noman Adiciona devel/imake como uma dependência de built-time e executa xmkmf -a durante o estágio configure. Se o argumento env é passado, o target configure não é definido. Se a flag for um problema para o port, adicione o argumento notall. E se xmkmf não gerar um target install.man, adicione o argumento noman. <literal>kde</literal> Argumentos possíveis: 5 Adiciona dependência de componentes KDE. Veja para maiores informações. <literal>kmod</literal> Argumentos possíveis: (none), debug Preenche o boilerplate para os ports de módulo do kernel, atualmente: Adiciona kld em CATEGORIES Define SSP_UNSAFE. Defina IGNORE se as fontes do kernel não forem encontradas em SRC_BASE. Define KMODDIR para /boot/modules por padrão, adiciona isso para a variável PLIST_SUB e MAKE_ENV, e o cria após a instalação. Se a variável KMODDIR está definida para o /boot/kernel, ela será reescrita para /boot/modules. Isso evita quebrar pacotes ao atualizar o kernel devido ao /boot/kernel ser renomeado para /boot/kernel.old no processo. Manipula módulos cross-referencing do kernel acerca da instalação e desinstalação, usando @kld. Se o argumento debug é passado, o port pode instalar uma versão de debug do módulo no arquivo KERN_DEBUGDIR/KMODDIR. Por padrão, a variável KERN_DEBUGDIR é copiada da DEBUGDIR e definido para /usr/lib/debug. O framework irá cuidar da criação e remoção de quaisquer diretórios necessários. <literal>lha</literal> Argumentos possíveis: (none) Define EXTRACT_SUFX para .lzh <literal>libarchive</literal> Argumentos possíveis: (none) Registra uma dependência de archivers/libarchive. Quaisquer ports dependendo de libarchive deve incluir USES=libarchive. <literal>libedit</literal> Argumentos possíveis: (none) Registra uma dependência de devel/libedit. Quaisquer ports dependendo de libedit devem incluir USES=libedit. <literal>libtool</literal> Argumentos possíveis: (none), keepla, build Scripts libtool de patches. Isso deve ser adicionado a todos os ports que usam libtool. O argumento keepla pode ser usado para manter arquivos .la. Alguns ports não vêm com sua própria cópia da libtool e precisam de uma dependência de devel/libtool em build time, use o argumento :build para adicionar essa dependência. <literal>linux</literal> Argumentos possíveis: c6, c7 Framework de compatibilidade de ports com Linux. Especifique c6 para depender de pacotes do CentOS 6. Especifique c7 para depender de pacotes do CentOS 7. Os pacotes disponíveis são: allegro alsa-plugins-oss alsa-plugins-pulseaudio alsalib atk avahi-libs base cairo cups-libs curl cyrus-sasl2 dbusglib dbuslibs devtools dri expat flac fontconfig gdkpixbuf2 gnutls graphite2 gtk2 harfbuzz jasper jbigkit jpeg libasyncns libaudiofile libelf libgcrypt libgfortran libgpg-error libmng libogg libpciaccess libsndfile libsoup libssh2 libtasn1 libthai libtheora libv4l libvorbis libxml2 mikmod naslibs ncurses-base nspr nss openal openal-soft openldap openmotif openssl pango pixman png pulseaudio-libs qt qt-x11 qtwebkit scimlibs sdl12 sdlimage sdlmixer sqlite3 tcl85 tcp_wrappers-libs tiff tk85 ucl xorglibs <literal>localbase</literal> Argumentos possíveis: (none), ldflags Garante que as bibliotecas de dependências em LOCALBASE sejam usadas ​​em vez das do sistema base. Especifique ldflags para adicionar -L${LOCALBASE}/lib para a variável LDFLAGS ao invés de LIBS. Ports que dependem de bibliotecas que também estão presentes no sistema base devem usar isso. Também é usado internamente por algumas outras variáveis USES. <literal>lua</literal> Argumentos possíveis: (none), XY+, XY, build, run Adiciona uma dependência de Lua. Por padrão, esta é uma dependência de biblioteca, a menos que seja invalidado por uma opção build ou run. A versão padrão é 5.2, a menos que seja definido pelo parâmetro XY (por exemplo, 51 ou 52+). <literal>lxqt</literal> Argumentos possíveis: (none) Manipular dependências para o LXQt Desktop Environment. Use a variável USE_LXQT para selecionar os componentes necessários para o port. Veja para maiores informações. <literal>makeinfo</literal> Argumentos possíveis: (none) Adiciona uma dependência de build-time em makeinfo se o mesmo não estiver presente no sistema base. <literal>makeself</literal> Argumentos possíveis: (none) Indica que os arquivos de distribuição são archives makeself e define as dependências apropriadas. <literal>mate</literal> Argumentos possíveis: (none) Fornece uma maneira fácil para depender de componentes do MATE. Os componentes devem ser listados em USE_MATE. Os componentes disponíveis são: autogen caja common controlcenter desktop dialogs docutils icontheme intlhack intltool libmatekbd libmateweather marco menus notificationdaemon panel pluma polkit session settingsdaemon A dependência padrão é em built-time e run-time, pode ser alterada com :build ou :run. Por exemplo: USES= mate USE_MATE= menus:build intlhack <literal>meson</literal> Argumentos possíveis: (none) Fornece suporte para projetos baseados no Meson. Para maiores informações, consulte . <literal>metaport</literal> Argumentos possíveis: (none) Define as seguintes variáveis ​​para facilitar a criação de um metaport: MASTER_SITES, DISTFILES, EXTRACT_ONLY, NO_BUILD, NO_INSTALL, NO_MTREE, NO_ARCH. <literal>mysql</literal> Argumentos possíveis: (none), version, client (padrão), server, embedded Fornece suporte para o MySQL. Se nenhuma versão for informada, tenta encontrar a versão atual instalada. Fall back para a versão padrão, MySQL-5.6. As possíveis versões são 55, 55m, 55p, 56, 56p, 56w, 57, 57p, 80, 100m, 101m e 102m. Os sufixos m e p são para MariaDB e Percona, variantes do MySQL. server e embbeded adicionam uma dependência de build- e run-time do servidor MySQL. Ao usar server ou embbeded, é adicionado client para também adicionar uma dependência no arquivo libmysqlclient.so. Um port pode definir IGNORE_WITH_MYSQL se algumas versões não forem suportadas. O framework define a variável MYSQL_VER para a versão detectada do MySQL. <literal>mono</literal> Argumentos possíveis: (none), nuget Adiciona uma dependência no framework Mono (atualmente apenas C#) definindo as dependências apropriadas. Especifique nuget quando o port usa pacotes nuget. NUGET_DEPENDS precisa ser definido com os nomes e versões dos pacotes nuget no formato name=version. Uma pacote de origem opcional pode ser adicionado usando name=version:origin. O target auxiliar, buildnuget, exibirá o conteúdo da variável NUGET_DEPENDS com base no arquivo packages.config fornecido. <literal>motif</literal> Argumentos possíveis: (none) Utiliza x11-toolkits/open-motif como uma dependência de biblioteca. Os usuários finais podem definir WANT_LESSTIF para a dependência estar em x11-toolkits/lesstif ao invés de x11-toolkits/open-motif. <literal>ncurses</literal> Argumentos possíveis: (none), base, port Utiliza ncurses, e faz com que algumas variáveis ​​úteis sejam definidas. <literal>ninja</literal> Argumentos possíveis: (none) Utiliza ninja para compilar o port. <literal>objc</literal> Argumentos possíveis: (none) Adiciona dependências de objetive C (compilador, biblioteca de runtime) se o sistema base não suportar isto. <literal>openal</literal> Argumentos possíveis: al, soft (padrão), yes, alut Utiliza OpenAL. O backend pode ser especificado, com a implementação do software como padrão. O usuário pode especificar um backend preferido com WANT_OPENAL. Os valores válidos para este manipulador são soft (padrão) e si. <literal>pathfix</literal> Argumentos possíveis: (none) Procura pelos arquivos Makefile.in e configure na variável PATHFIX_WRKSRC (padrão é WRKSRC) e corrige os caminhos comuns para garantir que eles respeitem a hierarquia do FreeBSD. Por exemplo, ele corrige o diretório de instalação dos arquivos .pc do pkgconfig para ${PREFIX}/libdata/pkgconfig. Se o port usa USES=autoreconf, Makefile.am será adicionado automaticamente a PATHFIX_MAKEFILEIN. Se o port tem definido USES=cmake ele vai procurar pelo arquivo CMakeLists.txt dentro da variável PATHFIX_WRKSRC. Se necessário, esse nome de arquivo padrão pode ser alterado com PATHFIX_CMAKELISTSTXT. <literal>pear</literal> Argumentos possíveis: env Adiciona uma dependência do devel/pear. Ele irá configurar o comportamento padrão do software usando o Repositório de Extensão e Aplicativos do PHP. O uso do argumento env apenas configura as variáveis de ambiente PEAR. Veja para maiores informações. <literal>perl5</literal> Argumentos possíveis: (none) Depende do Perl. A configuração é feita usando a variável USE_PERL5. USE_PERL5 pode conter as fases que precisam usar Perl, pode serextract, patch, build, run ou test. USE_PERL5 também pode conter configure, modbuild ou modbuildtiny quando Makefile.PL, Build.PL ou Módulo::Build::Tiny's, flavor de Build.PL é necessário. O padrão de USE_PERL5 é build run. Ao usar configure, modbuild ou modbuildtiny, uso de build e run são implícitos. Veja para maiores informações. <literal>pgsql</literal> Argumentos possíveis: (none), XY, XY+, XY- Fornece suporte ao PostgreSQL. O mantenedor pode definir a versão requisitada. Versões mínimas e máximas podem ser especificadas, por exemplo, 9.0-, 8.4+. Adicione a dependência do componente PostgreSQL, usando WANT_PGSQL=component[:target]. por exemplo, WANT_PGSQL=server:configure pltcl plperl. Os componentes disponíveis são: client contrib docs pgtcl plperl plpython pltcl server <literal>php</literal> Argumentos possíveis: (none), phpize, ext, zend, build, cli, cgi, mod, web, embed, pecl, flavors, noflavors Fornece suporte para o PHP. Adiciona uma dependência de run-time na versão padrão do PHP, lang/php56. phpize Utilizado para compilar uma extensão do PHP. Habilita flavors. ext Usado para compilar, instalar e registrar uma extensão do PHP. Habilita flavors. zend Usado para criar, instalar e registrar uma extensão do Zend. Habilita flavors. build Define PHP também como uma dependência de build-time. cli Precisa da versão CLI do PHP. cgi Precisa da versão CGI do PHP. mod Precisa do módulo Apache para o PHP. web Precisa do módulo Apache ou a versão CGI do PHP. embed Precisa da versão da biblioteca embarcada do PHP. pecl Fornece padrões para baixar extensões PHP do repositório PECL. Habilita flavors. flavors Habilita a geração de PHP flavors automático. Flavors serão gerados para todas as versões do PHP, exceto as presentes na variável IGNORE_WITH_PHP. noflavors Desativa a geração automática de flavors do PHP. Deve apenas ser usado com extensões fornecidas pelo próprio PHP. Variáveis ​​são usadas para especificar quais módulos PHP são necessários, bem como qual versão do PHP são suportadas. USE_PHP A lista das extensões PHP requisitadas em run-time. Adicione :build ao nome da extensão para adicionar uma dependência em build-time. Exemplo: pcre xml:build gettext IGNORE_WITH_PHP O port não funciona com a versão do PHP fornecida. Para possíveis valores, observe o conteúdo da variável _ALL_PHP_VERSIONS no arquivo Mk/Uses/php.mk. Ao compilar uma extensão do PHP ou Zend com :ext ou :zend, estas variáveis ​​podem ser definidas: PHP_MODNAME O nome da extensão do PHP ou Zend. O valor padrão é ${PORTNAME}. PHP_HEADER_DIRS Uma lista de subdiretórios dos quais instalar arquivos header. O framework sempre irá instalar os arquivos header que estão presentes no mesmo diretório que a extensão. PHP_MOD_PRIO A prioridade na qual carregar a extensão. É um número entre 00 e 99. Para extensões que não dependem de nenhuma extensão, a prioridade é definida automaticamente como 20, para extensões que dependem de outra extensão, a prioridade é definida automaticamente como 30. Algumas extensões podem precisar ser carregadas antes de todas as outras extensões, por exemplo www/php56-opcache. Algumas podem precisar ser carregadas após uma extensão com prioridade de 30. Nesse caso, adicione PHP_MOD_PRIO=XX no Makefile do port. Por exemplo: USES= php:ext USE_PHP= wddx PHP_MOD_PRIO= 40 Estas variáveis ​​estão disponíveis para uso em PKGNAMEPREFIX ou PKGNAMESUFFIX: PHP_PKGNAMEPREFIX Contém phpXY- onde XY é a versão do PHP atual. Use com módulos e extensões PHP. PHP_PKGNAMESUFFIX Contém -phpXY onde XY é a versão do PHP atual do flavor. Use com aplicativos PHP. PECL_PKGNAMEPREFIX Contém phpXY-pecl onde XY é a versão atual do PHP do flavor. Usar com módulos PECL. Com flavors, todas as extensões PHP, extensões PECL, módulos PEAR devem ter um nome de pacote diferente, então todos devem usar uma dessas três variáveis ​​em suas variáveis PKGNAMEPREFIX ou PKGNAMESUFFIX. <literal>pkgconfig</literal> Argumentos possíveis: (none), build (padrão), run, both Utiliza devel/pkgconf. Sem argumentos ou com o argumento build, implica em pkg-config como uma dependência de build-time. run implica em uma dependência em run-time e both implica em dependências de run-time e build-time. <literal>pure</literal> Argumentos possíveis: (none), ffi Utiliza lang/pure. Usado largamente para build relacionado com ports pure. Com o argumento ffi, isso implica em devel/pure-ffi como uma dependência em run-time. <literal>pyqt</literal> Argumentos possíveis: (none), 4, 5 Utiliza PyQt. Se o port é parte do próprio PyQT, defina PYQT_DIST. Use a variável USE_PYQT para selecionar os componentes que o port precisa. Os componentes disponíveis são: core dbus dbussupport demo designer designerplugin doc gui multimedia network opengl qscintilla2 sip sql svg test webkit xml xmlpatterns Estes componentes só estão disponíveis com PyQT4: assistant declarative help phonon script scripttools Estes componentes só estão disponíveis com PyQT5: multimediawidgets printsupport qml serialport webkitwidgets widgets A dependência padrão para cada componente são build e run-time, para selecionar apenas build ou run, adicione _build ou _run para o nome do componente. Por exemplo: USES= pyqt USE_PYQT= core doc_build designer_run <literal>python</literal> Argumentos possíveis: (none), XY, X.Y+, -XY, XY-ZA, patch, build, run, test Utiliza Python. Uma versão suportada ou um intervalo de versões podem ser especificados. Se o Python for necessário apenas no momento de build, run-time ou para os testes, ele pode ser definido como uma dependência de build, run ou teste com build, run ou test. Se o Python também for necessário durante a fase de patch, use patch. Veja para maiores informações. PYTHON_NO_DEPENDS=yes pode ser usado quando as variáveis ​​exportadas pelo framework serem necessárias, mas uma dependência de Python não. Pode acontecer quando usado com USES=shebangfix, e o objetivo é apenas consertar os shebangs, mas não adicionar uma dependência do Python. <literal>qmail</literal> Argumentos possíveis: (none), build, run, both, vars Utiliza mail/qmail. Com o argumento build, implica no qmail como uma dependência de build-time. run implica em uma dependência de run-time. Usando nenhum argumento ou o argumento both implica em dependências de run-time e build-time. vars só ira definir variáveis ​​QMAIL para o port usar. <literal>qmake</literal> Argumentos possíveis: (none), norecursive, outsource, no_env, no_configure Utiliza QMake para configuração. Para mais informações, veja . <literal>qt</literal> Argumentos possíveis: 5, no_env Adiciona dependência de componentes Qt. no_env é passado diretamente para USES= qmake. Veja para maiores informações. <literal>readline</literal> Argumentos possíveis: (none), port Usa readline como uma dependência de biblioteca e define CPPFLAGS e LDFLAGS como necessários. Se o argumento port é usado ou se readline não estiver presente no sistema base, adiciona uma dependência em devel/readline. <literal>samba</literal> Possíveis argumentos: build, env, lib, run Manipula dependências do Samba. env não irá adicionar qualquer dependência e apenas irá configurar as variáveis. build e run irão adicionar dependências de run-time e build-time de smbd. lib irá adicionar uma dependência em libsmbclient.so. As variáveis ​​que são exportadas são: SAMBAPORT A origem do port padrão Samba. SAMBAINCLUDES A localização dos arquivos header do Samba. SAMBALIBS O diretório onde as bibliotecas compartilhadas do Samba estão disponíveis. <literal>scons</literal> Argumentos possíveis: (none) Fornece suporte para o uso do devel/scons. Veja para maiores informações. <literal>shared-mime-info</literal> Argumentos possíveis: (none) Utiliza update-mime-database a partir de misc/shared-mime-info. Este uses irão adicionar automaticamente uma etapa de post-install de tal forma que o próprio port ainda possa especificar sua própria etapa de post-install, se necessário. Também adiciona uma entrada @shared-mime-info para o plist. <literal>shebangfix</literal> Argumentos possíveis: (none) Muitos softwares usam locais incorretos para interpretadores de scripts, principalmente /usr/bin/perl e /bin/bash. A macro shebangfix corrige linhas shebang em scripts listados em SHEBANG_REGEX, SHEBANG_GLOB ou SHEBANG_FILES. SHEBANG_REGEX Contém uma expressão regular estendida e é usado com o argumento -iregex do find1. Veja . SHEBANG_GLOB Contém uma lista de padrões usados com o argumento -name do find1. Veja . SHEBANG_FILES Contém uma lista de arquivos ou globs sh1. A macro shebangfix é executada a partir de ${WRKSRC}, assim SHEBANG_FILES pode conter caminhos relativos a ${WRKSRC}. Ele também pode lidar com caminhos absolutos se arquivos fora de ${WRKSRC} requisitarem uma correção. Veja . Atualmente Bash, Java, Ksh, Lua, Perl, PHP, Python, Rubi, Tcl e Tk são suportados por padrão. Aqui estão três variáveis de configuração: SHEBANG_LANG A lista de interpretadores suportados. interp_CMD O caminho para o interpretador de comandos no FreeBSD. O valor padrão é ${LOCALBASE}/bin/interp. interp_OLD_CMD A lista de invocações erradas de interpretadores. Estes são tipicamente caminhos obsoletos, ou caminhos usados ​​em outros sistemas operacionais que estão incorretos no FreeBSD. Eles serão substituídos pelo caminho correto na variável interp_CMD. Estes vão sempre ser parte da variável interp_OLD_CMD:"/usr/bin/envinterp" /bin/interp /usr/bin/interp /usr/local/bin/interp. A variável interp_OLD_CMD contém vários valores. Qualquer entrada com espaços deve estar entre aspas. Veja . A correção de shebangs é feita durante a fase patch. Se os scripts forem criados com shebangs incorretos durante a fase build, o processo de build (por exemplo, o script configure, ou o Makefiles) deve ser corrigido ou ter o caminho certo (por exemplo, com CONFIGURE_ENV, CONFIGURE_ARGS, MAKE_ENV ou MAKE_ARGS) para gerar as shebangs certas. Os caminhos corretos para os interpretadores suportados estão disponíveis em interp_CMD. Quando usado com USES=python, e o objetivo é apenas consertar os shebangs, mas a dependência de Python em si não é desejada, use a variável PYTHON_NO_DEPENDS=yes. Adicionando outro interpretadoror para <literal>USES=shebangfix</literal> Para adicionar outro interpretador, defina a variável SHEBANG_LANG. Por exemplo: SHEBANG_LANG= lua Especificando todos os Caminhos ao Adicionar um Interpretador para <literal>USES=shebangfix</literal> Se isto não estiver definido ainda, e não tiver valores padrão para interp_OLD_CMD e interp_CMD a entrada Ksh poderia ser definida como: SHEBANG_LANG= ksh ksh_OLD_CMD= "/usr/bin/env ksh" /bin/ksh /usr/bin/ksh ksh_CMD= ${LOCALBASE}/bin/ksh Adicionando uma Localização Estranha para um Interpretador Alguns softwares usam localizações estranhas para um interpretador. Por exemplo, um aplicativo pode esperar que Python esteja localizado em /opt/bin/python2.7. O caminho estranho a ser substituído pode ser declarado no Makefile do port: python_OLD_CMD= /opt/bin/python2.7 <literal>USES=shebangfix</literal> com a variável <varname>SHEBANG_REGEX</varname> Para corrigir todos os arquivos em ${WRKSRC}/scripts finalizados com .pl, .sh ou .cgi faça assim: USES= shebangfix SHEBANG_REGEX= ./scripts/.*\.(sh|pl|cgi) SHEBANG_REGEX é usada executando find -E, que usa expressões regulares modernas, também conhecidas como expressões regulares estendidas. Veja re_format7 para maiores informações. <literal>USES=shebangfix</literal> com a variável <varname>SHEBANG_GLOB</varname> Para corrigir todos os arquivos em ${WRKSRC} finalizados com .pl ou .sh, faça assim: USES= shebangfix SHEBANG_GLOB= *.sh *.pl <literal>USES=shebangfix</literal> com a variável <varname>SHEBANG_FILES</varname> Para corrigir os arquivos script/foobar.pl e script/*.sh dentro de ${WRKSRC}, faça assim: USES= shebangfix SHEBANG_FILES= scripts/foobar.pl scripts/*.sh <literal>sqlite</literal> Argumentos possíveis: (none), 2, 3 Adiciona uma dependência SQLite. A versão padrão usada é 3, mas usar a versão 2 também é possível usando o modificador :2. <literal>ssl</literal> Argumentos possíveis: (none), build, run Fornece suporte para OpenSSL. Uma dependência apenas de compilação ou run-time pode ser especificada usando build ou run. Estas variáveis estão disponíveis para uso do port, elas também são adicionadas para a variável MAKE_ENV: OPENSSLBASE Caminho para a base de instalação do OpenSSL. OPENSSLDIR Caminho para arquivos de configuração do OpenSSL. OPENSSLLIB Caminho para as bibliotecas do OpenSSL. OPENSSLINC Caminho para os includes do OpenSSL. OPENSSLRPATH Se definido, o caminho que o vinculador precisa usar para localizar as bibliotecas do OpenSSL. Se um port não for compilado com um flavor OpenSSL, defina a variável BROKEN_SSL, e possivelmente a variável BROKEN_SSL_REASON_flavor: BROKEN_SSL= libressl BROKEN_SSL_REASON_libressl= needs features only available in OpenSSL <literal>tar</literal> Argumentos possíveis: (none), Z, bz2, bzip2, lzma, tbz, tbz2, tgz, txz, xz Define a variável EXTRACT_SUFX para .tar, .tar.Z, .tar.bz2, .tar.bz2, .tar.lzma, .tbz, .tbz2, .tgz, .txz ou .tar.xz respectivamente. <literal>tcl</literal> Argumentos possíveis: version, wrapper, build, run, tea Adiciona uma dependência para o Tcl. Uma versão específica pode ser requisitada usando version. A versão pode estar vazia, um ou mais números exatos de versão (atualmente 84, 85 ou 86), ou um número mínimo de versão (atualmente84+, 85+ ou 86+). Para solicitar apenas um wrapper sem uma versão especifica, use wrapper. Uma dependência somente de compilação ou run-time pode ser especificada usando build ou run. Para compilar o port usando Tcl Extension Architecture, use o tea. Depois de incluir bsd.port.pre.mk o port pode inspecionar os resultados usando estas variáveis: TCL_VER: seleciona a versão major.minor do Tcl TCLSH: caminho completo do interpretador do Tcl TCL_LIBDIR: caminho das bibliotecas do Tcl TCL_INCLUDEDIR: caminho dos arquivos de cabeçalho C do Tcl TK_VER: versão major.minor do Tk que foi escolhida WISH: caminho completo do interpretador do Tk TK_LIBDIR: caminho das bibliotecas do Tk TK_INCLUDEDIR: caminho dos arquivos de cabeçalho C do Tk <literal>terminfo</literal> Argumentos possíveis: (none) Adiciona @terminfo ao arquivo plist. Use quando o port instalar arquivos *.terminfo em ${PREFIX}/share/misc. <literal>tk</literal> Os mesmos argumentos para tcl Um pequeno wrapper ao usar os dois Tcl e Tk. As mesmas variáveis são retornadas assim como quando estiver usando Tcl. <literal>uidfix</literal> Argumentos possíveis: (none) Altera algum comportamento padrão (principalmente de variáveis) do sistema de compilação para permitir instalar este port como um usuário normal. Tente isso no port antes de usar USES=fakeroot ou de aplicar algum patch. <literal>uniquefiles</literal> Argumentos possíveis: (none), dirs Torna arquivos ou diretórios 'exclusivos', adicionando um prefixo ou sufixo. Se o argumento dirs é usado, o port precisa de um prefixo (e apenas um prefixo) baseado em UNIQUE_PREFIX para diretórios padrão DOCSDIR, EXEMPLESDIR, DATADIR, WWWDIR, ETCDIR. Estas variáveis estão disponíveis para os ports: UNIQUE_PREFIX: O prefixo a ser usado para diretórios e arquivos. Padrão: ${PKGNAMEPREFIX}. UNIQUE_PREFIX_FILES: Uma lista de arquivos que precisam ser prefixados. Padrão: vazio. UNIQUE_SUFFIX: O sufixo para ser usado por arquivos. Padrão: ${PKGNAMESUFFIX}. UNIQUE_SUFFIX_FILES: Uma lista de arquivos que precisam estar com um sufixo. Padrão: vazio. <literal>varnish</literal> Argumentos possíveis: 4, 5 Manipula dependências do Varnish Cache. 4 irá adicionar uma dependência do www/varnish4. 5 irá adicionar uma dependência do www/varnish5. <literal>webplugin</literal> Argumentos possíveis: (none), ARGS Cria e remove automaticamente links simbólicos para cada aplicação que suporta o framework do webplugin. ARGS pode ser um dos: gecko: suporte a plug-ins baseados no Gecko native: suporte a plug-ins para o Gecko, Opera e WebKit-GTK linux: suporte a plug-ins do Linux all (padrão, implícito): suporta todos os tipos de plug-ins (entradas individuais): suporta apenas os navegadores listados Essas variáveis podem ser ajustadas: WEBPLUGIN_FILES: Sem padrão, deve ser definido manualmente. Os arquivos de plug-in para instalar. WEBPLUGIN_DIR: O diretório para instalar os arquivos de plug-in, padrão PREFIX/lib/browser_plugins/WEBPLUGIN_NAME. Defina isso se o port instalar arquivos de plug-in fora do diretório padrão para previnir links simbólicos quebrados. WEBPLUGIN_NAME: O diretório final para instalar os arquivos de plug-in, padrão PKGBASE. <literal>xfce</literal> Argumentos possíveis: (none), gtk3 Fornece suporte para ports relacionados ao Xfce. Veja para detalhes. O argumento gtk3 especifica que o port requer suporte a GTK3. Ele adiciona recursos adicionais fornecidos por alguns componentes principais, por exemplo, x11/libxfce4menu e x11-wm/xfce4-panel. <literal>zip</literal> Argumentos possíveis: (none), infozip Indica que os arquivos de distribuição usam o algoritmo de compactação ZIP. Para arquivos que usam o algoritmo InfoZip, o argumento infozip deve ser passado para definir as dependências apropriadas. <literal>zope</literal> Argumentos possíveis: (none) Utiliza www/zopeXY. Usado principalmente para a compilação de ports relacionados ao zope. ZOPE_VERSION pode ser usado por um port para indicar que uma versão específica do zope deve ser usada. Valores <literal>__FreeBSD_version</literal> Aqui está uma lista conveniente dos valores __FreeBSD_version definidos em sys/param.h: Versões do FreeBSD 13 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 13 Valor Revisão Data Release 1300000 339436 19 de outubro de 2018 13.0-CURRENT. 1300001 339730 25 de outubro de 2018 13.0-CURRENT after bumping OpenSSL shared library version numbers. 1300002 339765 25 de outubro de 2018 13.0-CURRENT after restoration of sys/joystick.h. 1300003 340055 2 de novembro de 2018 13.0-CURRENT after vop_symlink API change (a_target is now const.) 1300004 340841 23 de novembro de 2018 13.0-CURRENT depois de habilitar o código crtbegin e crtend 1300005 341836 11 de dezembro de 2018 13.0-CURRENT depois de habilitar checksums para inodes do UFS. 1300006 342398 24 de dezembro de 2018 13.0-CURRENT depois de consertar o include sys/random.h para ser utilizável em C ++. 1300007 342629 30 de dezembro de 2018 13.0-CURRENT depois de mudar o tamanho do struct linux_cdev nas plataformas de 32-bits. 1300008 342772 4 de janeiro de 2019 13.0-CURRENT depois de adicionar os sysctls kern.smp.threads_per_core e kern.smp.cores. 1300009 343213 20 de janeiro de 2019 13.0-CURRENT após a modificação da estrutura struct ieee80211vap para resolver a corrida ioctl/detach para a estrutura ieee80211com. 1300010 343485 27 de janeiro de 2019 13.0-CURRENT depois de incrementar o SPECNAMELEN de 63 para MAXNAMELEN (255). 1300011 344041 12 de fevereiro de 2019 13.0-CURRENT depois que o renameat2 foi corrigido para funcionar com kernels construídos com a opção CAPABILITIES. 1300012 344062 12 de fevereiro de 2019 13.0-CURRENT após taskqgroup_attach() e taskqgroup_attach_cpu() tomar um device_t e um ponteiro de recurso struct como argumentos para denotar interrupções de dispositivo. 1300013 344300 19 de fevereiro de 2019 13.0-CURRENT após a remoção do drm e do drm2. 1300014 344779 4 de março de 2019 13.0-CURRENT depois de atualizar o clang, llvm, lld, lldb, compiler-rt e libc++ para a 8.0.0 rc3. 1300015 345196 15 de março de 2019 13.0-CURRENT depois de desanonimizar as threads e os proc state enums, de forma que as aplicações userland podem usá-las sem redefinir os nomes dos valores. 1300016 345236 16 de março de 2019 13.0-CURRENT depois de habilitar o código crtbegin e crtend + + + 1300017 + 345305 + 19 de março de 2019 + 13.0-CURRENT after exposing the Rx mbuf buffer size to drivers in iflib. + + + + 1300018 + 346012 + 16 de março de 2019 + 13.0-CURRENT after introduction of funlinkat syscall in 345982. + + + + 1300019 + 346282 + 16 de abril de 2019 + 13.0-CURRENT after addition of is_random_seeded(9) to random4. + + + + 1300020 + 346358 + 18 de abril de 2019 + 13.0-CURRENT after restoring random4 availability tradeoff prior to 346250 and adding new tunables and diagnostic sysctls for programmatically discovering early seeding problems after boot. + + + + + + 1300021 + 346645 + 24 de abril de 2019 + 13.0-CURRENT after LinuxKPI uses bus_dma9 to be compatible with an IOMMU. + + + + 1300022 + 347089 + 4 de maio de 2019 + 13.0-CURRENT after fixing regression issue after r346645 in the LinuxKPI. + + + + 1300023 + 347192 + 6 de maio de 2019 + 13.0-CURRENT after list-ifying kernel dump device configuration. + + + + 1300024 + 347325 + 8 de maio de 2019 + 13.0-CURRENT after bumping the Mellanox driver version numbers (mlx4en4; mlx5en4). + + + + 1300025 + r347532 + 13 de maio de 2019 + 13.0-CURRENT after renaming vm.max_wired to vm.max_user_wired and changing its type. + + + + 1300026 + 347596 + 14 de maio de 2019 + 13.0-CURRENT after adding context member to ww_mutex in LinuxKPI. + + + + 1300027 + 347601 + 14 de maio de 2019 + 13.0-CURRENT after adding prepare to pm_ops in LinuxKPI. + + + + 1300028 + 347925 + 17 de maio de 2019 + 13.0-CURRENT after removal of bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, and xe drivers. + + + + 1300029 + 347984 + 20 de maio de 2019 + 13.0-CURRENT after removing some header pollution due to sys/eventhandler.h. Affected files may now need to explicitly include one or more of sys/eventhandler.h, sys/ktr.h, sys/lock.h, or sys/mutex.h, when the missing header may have been included implicitly prior to 1300029. + + + + 1300030 + 348350 + 29 de maio de 2019 + 13.0-CURRENT after adding relocation support to libdwarf on powerpc64 to fix handling of DWARF information on unlinked objects. Original commit in 348347. + + + + 1300031 + 348808 + 8 de junho de 2019 + 13.0-CURRENT after adding dpcpu and vnet section fixes to i386 kernel modules to avoid panics in certain conditions. i386 kernel modules need to be recompiled with the linker script magic in place or they will refuse to load. +
Versões do FreeBSD 12 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 12 Valor Revisão Data Release 1200000 302409 7 de julho de 2016 12.0-CURRENT. 1200001 302628 12 de julho de 2016 12.0-CURRENT after removing collation from [a-z]-type ranges. 1200002 304395 18 de agosto de 2016 12.0-CURRENT after removing unused and obsolete openbsd_poll system call. 1200003 304608 22 de agosto de 2016 12.0-CURRENT after adding C++11 thread_local support in rev 303795. 1200004 304752 24 de agosto de 2016 12.0-CURRENT after fixing LC_*_MASK for newlocale3 and querylocale3 (rev 304703). 1200005 304789 25 de agosto de 2016 12.0-CURRENT after changing some ioctl interfaces in rev 304787 between the iSCSI userspace programs and the kernel. 1200006 305256 1º de setembro de 2016 12.0-CURRENT after crunchgen1 META_MODE fix in 305254. 1200007 305421 5 de setembro de 2016 12.0-CURRENT after resolving a deadlock between device_detach() and usbd_do_request_flags9. 1200008 305833 15 de setembro de 2016 12.0-CURRENT after removing the 4.3BSD compatible macro m_copy() in 305824. 1200009 306077 21 de setembro de 2016 12.0-CURRENT after removing bio_taskqueue() in 305988. 1200010 306276 23 de setembro de 2016 12.0-CURRENT after mounting msdosfs5 with longnames support by default. 1200011 306556 1 de outubro de 2016 12.0-CURRENT after adding fb_memattr field to fb_info in 306555. 1200012 306592 2 de outubro de 2016 12.0-CURRENT after net802114 changes (rev 306590, 306591). 1200013 307140 12 de outubro de 2016 12.0-CURRENT after installing header files required development with libzfs_core. 1200014 307529 17 de outubro de 2016 12.0-CURRENT after merging common code in rtwn4 and urtwn4, and adding support for 802.11ac devices. 1200015 308874 20 de novembro de 2016 12.0-CURRENT after some ABI change for unbreaking powerpc. 1200016 309017 22 de novembro de 2016 12.0-CURRENT after removing PG_CACHED-related fields from vmmeter. 1200017 309124 25 de novembro de 2016 12.0-CURRENT after upgrading our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and adding lld 3.9.0. 1200018 309676 7 de dezembro de 2016 12.0-CURRENT after adding the ki_moretdname member to struct kinfo_proc and struct kinfo_proc32 to export the whole thread name to user-space utilities. 1200019 310149 16 de dezembro de 2016 12.0-CURRENT after starting to lay down the foundation for 11ac support. 1200020 312087 13 de janeiro de 2017 12.0-CURRENT after removing fgetsock and fputsock. 1200021 313858 16 de fevereiro de 2017 12.0-CURRENT after removing MCA and EISA support. 1200022 314040 21 de fevereiro de 2017 12.0-CURRENT after making the LinuxKPI task struct persistent across system calls. (Não mudou) 314373 2 de março de 2017 12.0-CURRENT after removing System V Release 4 binary compatibility support. 1200023 314564 2 de março de 2017 12.0-CURRENT after upgrading our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0. 1200024 314865 7 de março de 2017 12.0-CURRENT after removal of pcap-int.h 1200025 315430 16 de março de 2017 12.0-CURRENT after addition of the <dev/mmc/mmc_ioctl.h> header. 1200026 315662 16 de março de 2017 12.0-CURRENT after hiding struct inpcb and struct tcpcb from userland. 1200027 315673 21 de março de 2017 12.0-CURRENT after making CAM SIM lock optional. 1200028 316683 10 de abril de 2017 12.0-CURRENT after renaming smp_no_rendevous_barrier() to smp_no_rendezvous_barrier() in 316648. 1200029 317176 19 de abril de 2017 12.0-CURRENT after the removal of struct vmmeter from struct pcpu from 317061. 1200030 317383 24 de abril de 2017 12.0-CURRENT after removing NATM support including en4, fatm4, hatm4, and patm4. 1200031 318736 23 de maio de 2017 12.0-CURRENT after types ino_t, dev_t, nlink_t were extended to 64bit and struct dirent changed layout (also known as ino64). 1200032 319664 8 de junho de 2017 12.0-CURRENT after removal of groff. 1200033 320043 17 de junho de 2017 12.0-CURRENT after the type of the struct event member data was increased to 64bit, and ext structure members added. 1200034 320085 19 de junho de 2017 12.0-CURRENT after the NFS client and server were changed so that they actually use the 64bit ino_t. 1200035 320317 24 de junho de 2017 12.0-CURRENT after the MAP_GUARD mmap2 flag was added. 1200036 320347 26 de junho de 2017 12.0-CURRENT after changing time_t to 64 bits on powerpc (32-bit version). 1200037 320545 1º de julho de 2017 12.0-CURRENT after the cleanup and inlining of bus_dmamap* functions (320528). 1200038 320879 10 de julho de 2017 12.0-CURRENT after MMC CAM committed. (320844). 1200039 r321369 22 de julho de 2017 12.0-CURRENT after upgrade of copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 (trunk r308421). 1200040 r321688 29 de julho de 2017 12.0-CURRENT after adding NFS client forced dismount support umount -N. 1200041 r322762 21 de agosto de 2017 12.0-CURRENT after WRFSBASE instruction become operational on amd64. 1200042 r322900 25 de agosto de 2017 12.0-CURRENT after PLPMTUD counters were changed to use counter9. 1200043 r322989 28 de agosto de 2017 12.0-CURRENT after dropping x86 CACHE_LINE_SIZE down to 64 bytes. 1200044 r323349 8 de setembro de 2017 12.0-CURRENT after implementing poll_wait() in the LinuxKPI. 1200045 r323706 18 de setembro de 2017 12.0-CURRENT after adding shared memory support to LinuxKPI. (r323703). 1200046 r323910 22 de setembro de 2017 12.0-CURRENT after adding support for 32-bit compatibility IOCTLs to LinuxKPI. 1200047 r324053 26 de setembro de 2017 12.0-CURRENT after removing M_HASHTYPE_RSS_UDP_IPV4_EX. (r324052). 1200048 r324227 2 de outubro de 2017 12.0-CURRENT after hiding struct socket and struct unpcb from userland. 1200049 r324281 4 de outubro de 2017 12.0-CURRENT after adding the value.u16 field to struct diocgattr_arg. 1200050 r324342 5 de outubro de 2017 12.0-CURRENT after adding the armv7 MACHINE_ARCH. (r324340). 1200051 r324455 9 de outubro de 2017 12.0-CURRENT after removing libstand.a as a public interface. (r324454). 1200052 r325028 26 de outubro de 2017 12.0-CURRENT after fixing ptrace() to always clear the correct thread event when resuming. 1200053 r325506 7 de novembro de 2017 12.0-CURRENT after changing struct mbuf layout to add optional hardware timestamps for receive packets. 1200054 r325852 15 de novembro de 2017 12.0-CURRENT after changing the layout of struct vmtotal to allow for reporting large memory counters. 1200055 r327740 9 de janeiro de 2018 12.0-CURRENT after adding cpucontrol -e support. 1200056 r327952 14 de janeiro de 2018 12.0-CURRENT after upgrading clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r321788). 1200057 r329033 8 de fevereiro de 2018 12.0-CURRENT after applying a clang 6.0.0 fix to make the wine ports build correctly. 1200058 r329166 12 de fevereiro de 2018 12.0-CURRENT após o lua loader ser inserido. 1200059 r330299 2 de março de 2018 12.0-CURRENT after removing the declaration of union semun unless _WANT_SEMUN is defined. Also the removal of struct mymsg and the renaming of kernel-only members of struct semid_ds and struct msgid_ds. 1200060 r330384 4 de março de 2018 12.0-CURRENT after upgrading clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 release. 1200061 r332100 6 de abril de 2018 12.0-CURRENT after changing syslog3 to emit RFC 5424 formatted messages. 1200062 r332423 12 de abril de 2018 12.0-CURRENT after changing the Netmap API. 1200063 r333446 10 de maio de 2018 12.0-CURRENT after reworking CTL frontend and backend options to use nv3, allow creating multiple ioctl frontend ports. 1200064 r334074 22 de maio de 2018 12.0-CURRENT after changing the ifnet address and multicast address TAILQ to CK_STAILQ. 1200065 r334290 28 de maio de 2018 12.0-CURRENT after changing dwatch1 to allow '-E code' to override profile EVENT_DETAILS. 1200066 r334466 1 de junho de 2018 12.0-CURRENT after removal of in-kernel pmc tables for Intel. 1200067 r334892 9 de junho de 2018 12.0-CURRENT after adding DW_LANG constants to libdwarf. 1200068 r334930 12 de junho de 2018 12.0-CURRENT after changing the interface between the NFS modules. 1200069 r335237 15 de junho de 2018 12.0-CURRENT after changing struct kerneldumpheader to version 4 (similar to version 2 in 11-STABLE and previous). 1200070 r335873 2 de julho de 2018 12.0-CURRENT after inlining atomic9 in modules on amd64 and i386 requiring all modules of consumers to be rebuilt for these architectures. 1200071 r335930 4 de julho de 2018 12.0-CURRENT after changing the ABI and API of epoch9 (r335924) requiring modules of consumers to be rebuilt. 1200072 r335979 5 de julho de 2018 12.0-CURRENT after changing the ABI and API of struct xinpcb and friends. 1200073 r336313 15 de julho de 2018 12.0-CURRENT after changing the ABI and API of struct if_shared_ctx and struct if_softc_ctx requiring modules of iflib9 consumers to be rebuilt. 1200074 r336360 16 de julho de 2018 12.0-CURRENT after updating the configuration of libstdc++ to make use of C99 functions. 1200075 r336538 19 de julho de 2018 12.0-CURRENT after zfsloader being folded into loader, and after adding ntpd:ntpd as uid:gid 123:123, and after removing arm big-endian support (MACHINE_ARCH=armeb). 1200076 r336914 30 de julho de 2018 12.0-CURRENT after KPI changes to timespecadd. 1200077 r337576 10 de agosto de 2018 12.0-CURRENT after timespec_get was added to the system. 1200078 r337863 15 de agosto de 2018 12.0-CURRENT after exec.created hook for jails. 1200079 r338061 19 de agosto de 2018 12.0-CURRENT after converting arc4random to using the Chacha20 algorithm and deprecating arc4random_stir and arc4random_addrandom. 1200080 r338172 22 de agosto de 2018 12.0-CURRENT after removing the drm drivers. 1200081 r338182 21 de agosto de 2018 12.0-CURRENT after KPI changes to NVMe. 1200082 r338285 24 de agosto de 2018 12.0-CURRENT after reverting the removal of the drm drivers. 1200083 r338331 26 de agosto de 2018 12.0-CURRENT after removing arc4random_stir and arc4random_addrandom. 1200084 r338478 5 de setembro de 2018 12.0-CURRENT after updating objcopy1 to properly handle little-endian MIPS64 object files. 1200085 r339270 19 de outubro de 2018 12.0-STABLE after updating OpenSSL to version 1.1.1. 1200086 r339732 25 de outubro de 2018 12.0-STABLE after updating OpenSSL shared library version numbers. 1200500 r340471 16 de novembro de 2018 12-STABLE after releng/12.0 was branched. 1200501 r342801 6 de janeiro de 2019 12-STABLE após o merge do fix para o comportamento do linux_destroy_dev () quando ainda existem arquivos abertos a partir da cdev que esta sendo destruída. 1200502 r343126 17 de janeiro de 2019 12-STABLE após habilitar o sys/random.h #include do C ++. 1200503 r344152 15 de fevereiro de 2019 12-STABLE após o merge do fix do renameat (2) para kernels CAPABILITIES. + + + 1200504 + r345169 + 15 de março de 2019 + 12-STABLE after merging CCM for the benefit of the ZoF port. + + + + 1200505 + r345327 + 20 de março de 2019 + 12-STABLE after merging support for selectively disabling ZFS without disabling loader. + + + + 1200506 + r346168 + 12 de abril de 2019 + 12-STABLE after merging llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. +
Versões do FreeBSD 11 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 11 Valor Revisão Data Release 1100000 256284 10 de outubro de 2013 11.0-CURRENT. 1100001 256776 19 de outubro de 2013 11.0-CURRENT after addition of support for "first boot" rc.d scripts, so ports can make use of this. 1100002 257696 5 de novembro de 2013 11.0-CURRENT after dropping support for historic ioctls. 1100003 258284 17 de novembro de 2013 11.0-CURRENT after iconv changes. 1100004 259424 15 de dezembro de 2013 11.0-CURRENT after the behavior change of gss_pseudo_random introduced in 259286. 1100005 260010 28 de dezembro de 2013 11.0-CURRENT after 259951 - Do not coalesce entries in vm_map_stack9. 1100006 261246 28 de janeiro de 2014 11.0-CURRENT after upgrades of libelf and libdwarf. 1100007 261283 30 de janeiro de 2014 11.0-CURRENT after upgrade of libc++ to 3.4 release. 1100008 261881 14 de fevereiro de 2014 11.0-CURRENT after libc++ 3.4 ABI compatibility fix. 1100009 261991 16 de fevereiro de 2014 11.0-CURRENT after upgrade of llvm/clang to 3.4 release. 1100010 262630 28 de fevereiro de 2014 11.0-CURRENT after upgrade of ncurses to 5.9 release (rev 262629). 1100011 263102 13 de março de 2014 11.0-CURRENT after ABI change in struct if_data. 1100012 263140 14 de março de 2014 11.0-CURRENT after removal of Novell IPX protocol support. 1100013 263152 14 de março de 2014 11.0-CURRENT after removal of AppleTalk protocol support. 1100014 263235 16 de março de 2014 11.0-CURRENT after renaming <sys/capability.h> to <sys/capsicum.h> to avoid a clash with similarly named headers in other operating systems. A compatibility header is left in place to limit build breakage, but will be deprecated in due course. 1100015 263620 22 de março de 2014 11.0-CURRENT after cnt rename to vm_cnt. 1100016 263660 23 de março de 2014 11.0-CURRENT after addition of armv6hf TARGET_ARCH. 1100017 264121 4 de abril de 2014 11.0-CURRENT after GCC support for __block definition. 1100018 264212 6 de abril de 2014 11.0-CURRENT after support for UDP-Lite protocol (RFC 3828). 1100019 264289 8 de abril de 2014 11.0-CURRENT after FreeBSD-SA-14:06.openssl (rev 264265). 1100020 265215 1 de maio de 2014 11.0-CURRENT after removing lindev in favor of having /dev/full by default (rev 265212). 1100021 266151 6 de maio de 2014 11.0-CURRENT after src.opts.mk changes, decoupling make.conf5 from buildworld (rev 265419). 1100022 266904 30 de maio de 2014 11.0-CURRENT after changes to strcasecmp3, moving strcasecmp_l3 and strncasecmp_l3 from <string.h> to <strings.h> for POSIX 2008 compliance (rev 266865). 1100023 267440 13 de junho de 2014 11.0-CURRENT after the CUSE library and kernel module have been attached to the build by default. 1100024 267992 27 de junho de 2014 11.0-CURRENT after sysctl3 API change. 1100025 268066 30 de junho de 2014 11.0-CURRENT after regex3 library update to add > and < delimiters. 1100026 268118 1 de julho de 2014 11.0-CURRENT after the internal interface between the NFS modules, including the krpc, was changed by (rev 268115). 1100027 268441 8 de julho de 2014 11.0-CURRENT after FreeBSD-SA-14:17.kmem (rev 268431). 1100028 268945 21 de julho de 2014 11.0-CURRENT after hdestroy3 compliance fix changed ABI. 1100029 270173 3 de agosto de 2014 11.0-CURRENT after SOCK_DGRAM bug fix (rev 269489). 1100030 270929 1º de setembro de 2014 11.0-CURRENT after SOCK_RAW sockets were changed to not modify packets at all. 1100031 271341 9 de setembro de 2014 11.0-CURRENT after FreeBSD-SA-14:18.openssl (rev 269686). 1100032 271438 11 de setembro de 2014 11.0-CURRENT after API changes to ifa_ifwithbroadaddr, ifa_ifwithdstaddr, ifa_ifwithnet, and ifa_ifwithroute. 1100033 271657 9 de setembro de 2014 11.0-CURRENT after changing access, eaccess, and faccessat to validate the mode argument. 1100034 271686 16 de setembro de 2014 11.0-CURRENT after FreeBSD-SA-14:19.tcp (rev 271666). 1100035 271705 17 de setembro de 2014 11.0-CURRENT after i915 HW context support. 1100036 271724 17 de setembro de 2014 Version bump to have ABI note distinguish binaries ready for strict mmap2 flags checking (rev 271724). 1100037 272674 6 de outubro de 2014 11.0-CURRENT after addition of explicit_bzero3 (rev 272673). 1100038 272951 11 de outubro de 2014 11.0-CURRENT after cleanup of TCP wrapper headers. 1100039 273250 18 de outubro de 2014 11.0-CURRENT after removal of MAP_RENAME and MAP_NORESERVE. 1100040 273432 21 de outubro de 2014 11.0-CURRENT after FreeBSD-SA-14:23 (rev 273146). 1100041 273875 30 de outubro de 2014 11.0-CURRENT after API changes to syscall_register, syscall32_register, syscall_register_helper and syscall32_register_helper (rev 273707). 1100042 274046 3 de novembro de 2014 11.0-CURRENT after a change to struct tcpcb. 1100043 274085 4 de novembro de 2014 11.0-CURRENT after enabling vt4 by default. 1100044 274116 4 de novembro de 2014 11.0-CURRENT after adding new libraries/utilities (dpv and figpar) for data throughput visualization. 1100045 274162 4 de novembro de 2014 11.0-CURRENT after FreeBSD-SA-14:23, FreeBSD-SA-14:24, and FreeBSD-SA-14:25. 1100046 274470 13 de novembro de 2014 11.0-CURRENT after kern_poll signature change (rev 274462). 1100047 274476 13 de novembro de 2014 11.0-CURRENT after removal of no-at version of VFS syscalls helpers, like kern_open. 1100048 275358 1º de dezembro de 2014 11.0-CURRENT after starting the process of removing the use of the deprecated "M_FLOWID" flag from the network code. 1100049 275633 9 de dezembro de 2014 11.0-CURRENT after importing an important fix to the LLVM vectorizer, which could lead to buffer overruns in some cases. 1100050 275732 12 de dezembro de 2014 11.0-CURRENT after adding AES-ICM and AES-GCM to OpenCrypto. 1100051 276096 23 de dezembro de 2014 11.0-CURRENT after removing old NFS client and server code from the kernel. 1100052 276479 31 de dezembro de 2014 11.0-CURRENT after upgrade of clang, llvm and lldb to 3.5.0 release. 1100053 276781 7 de janeiro de 2015 11.0-CURRENT after MCLGET9 gained a return value (rev 276750). 1100054 277213 15 de janeiro de 2015 11.0-CURRENT after rewrite of callout subsystem. 1100055 277528 22 de janeiro de 2015 11.0-CURRENT after reverting callout changes in 277213. 1100056 277610 23 de janeiro de 2015 11.0-CURRENT after addition of futimens and utimensat system calls. 1100057 277897 29 de janeiro de 2015 11.0-CURRENT after removal of d_thread_t. 1100058 278228 5 de fevereiro de 2015 11.0-CURRENT after addition of support for probing the SCSI VPD Extended Inquiry page (0x86). 1100059 278442 9 de fevereiro de 2015 11.0-CURRENT after import of xz 5.2.0, which added multi-threaded compression and lzma gained libthr dependency (rev 278433). 1100060 278846 16 de fevereiro de 2015 11.0-CURRENT after forwarding FBIO_BLANK to framebuffer clients. 1100061 278964 18 de fevereiro de 2015 11.0-CURRENT after CDAI_FLAG_NONE addition. 1100062 279221 23 de fevereiro de 2015 11.0-CURRENT after mtio4 and sa4 API and ioctl2 additions. 1100063 279728 7 de março de 2015 11.0-CURRENT after adding mutex support to the pps_ioctl() API in the kernel. 1100064 279729 7 de março de 2015 11.0-CURRENT after adding PPS support to USB serial drivers. 1100065 280031 15 de março de 2015 11.0-CURRENT after upgrading clang, llvm and lldb to 3.6.0. 1100066 280306 20 de março de 2015 11.0-CURRENT after removal of SSLv2 support from OpenSSL. 1100067 280630 25 de março de 2015 11.0-CURRENT after removal of SSLv2 support from fetch1 and fetch3. 1100068 281172 6 de abril de 2015 11.0-CURRENT after change to net.inet6.ip6.mif6table sysctl. 1100069 281550 15 de abril de 2015 11.0-CURRENT after removal of const qualifier from iconv3. 1100070 281613 16 de abril de 2015 11.0-CURRENT after moving ALTQ from contrib to net/altq. 1100071 282256 29 de abril de 2015 11.0-CURRENT after API/ABI change to smb4 (rev 281985). 1100072 282319 1 de maio de 2015 11.0-CURRENT after adding reallocarray3 in libc (rev 282314). 1100073 282650 8 de maio de 2015 11.0-CURRENT after extending the maximum number of allowed PCM channels in a PCM stream to 127 and decreasing the maximum number of sub-channels to 1. 1100074 283526 25 de maio de 2015 11.0-CURRENT after adding preliminary support for x86-64 Linux binaries (rev 283424), and upgrading clang and llvm to 3.6.1. 1100075 283623 27 de maio de 2015 11.0-CURRENT after dounmount()requiring a reference on the passed struct mount (rev 283602). 1100076 283983 4 de junho de 2015 11.0-CURRENT after disabled generation of legacy formatted password databases entries by default. 1100077 284233 10 de junho de 2015 11.0-CURRENT after API changes to lim_cur, lim_max, and lim_rlimit (rev 284215). 1100078 286672 12 de agosto de 2015 11.0-CURRENT after crunchgen1 changes from 284356 to 285986. 1100079 286874 18 de agosto de 2015 11.0-CURRENT after import of jemalloc 4.0.0 (rev 286866). 1100080 288943 5 de outubro de 2015 11.0-CURRENT after upgrading clang, llvm, lldb, compiler-rt and libc++ to 3.7.0. 1100081 289415 16 de outubro de 2015 11.0-CURRENT after undating ZFS to support resumable send/receive (rev 289362). 1100082 289594 19 de outubro de 2015 11.0-CURRENT after Linux KPI updates. 1100083 289749 22 de outubro de 2015 11.0-CURRENT after renaming linuxapi.ko to linuxkpi.ko. 1100084 290135 29 de outubro de 2015 11.0-CURRENT after moving the LinuxKPI module into the default kernel build. 1100085 290207 30 de outubro de 2015 11.0-CURRENT after import of OpenSSL 1.0.2d. 1100086 290275 2 de novembro de 2015 11.0-CURRENT after making figpar3 macros more unique. 1100087 290479 7 de novembro de 2015 11.0-CURRENT after changing sysctl_add_oid9's ABI. 1100088 290495 7 de novembro de 2015 11.0-CURRENT after string collation and locales rework. 1100089 290505 7 de novembro de 2015 11.0-CURRENT after API change to sysctl_add_oid9 (rev 290475). 1100090 290715 10 de novembro de 2015 11.0-CURRENT after API change to callout_stop macro; (rev 290664). 1100091 291537 30 de novembro de 2015 11.0-CURRENT after changing the interface between the nfsd.ko and nfscommon.ko modules in 291527. 1100092 292499 19 de dezembro de 2015 11.0-CURRENT after removal of vm_pageout_grow_cache (rev 292469). 1100093 292966 30 de dezembro de 2015 11.0-CURRENT after removal of sys/crypto/sha2.h (rev 292782). 1100094 294086 15 de janeiro de 2016 11.0-CURRENT after LinuxKPI PCI changes (rev 294086). 1100095 294327 19 de janeiro de 2016 11.0-CURRENT after LRO optimizations. 1100096 294505 21 de janeiro de 2016 11.0-CURRENT after LinuxKPI idr_* additions. 1100097 294860 26 de janeiro de 2016 11.0-CURRENT after API change to dpv3. 1100098 295682 16 de fevereiro de 2016 11.0-CURRENT after API change to rman (rev 294883). 1100099 295739 18 de fevereiro de 2016 11.0-CURRENT after allowing drivers to set the TCP ACK/data segment aggregation limit. 1100100 296136 26 de fevereiro de 2016 11.0-CURRENT after bus_alloc_resource_any9 API addition. 1100101 296417 5 de março de 2016 11.0-CURRENT after upgrading our copies of clang, llvm, lldb and compiler-rt to 3.8.0 release. 1100102 296749 12 de março de 2016 11.0-CURRENT after libelf cross-endian fix in rev 296685. 1100103 297000 18 de março de 2016 11.0-CURRENT after using uintmax_t for rman ranges. 1100104 297156 21 de março de 2016 11.0-CURRENT after tracking filemon usage via a proc.p_filemon pointer rather than its own lists. 1100105 297602 6 de abril de 2016 11.0-CURRENT after fixing sed functions i and a from discarding leading white space. 1100106 298486 22 de abril de 2016 11.0-CURRENT after fixes for using IPv6 addresses with RDMA. 1100107 299090 4 de maio de 2016 11.0-CURRENT after improving performance and functionality of the bitstring3 api. 1100108 299530 12 de maio de 2016 11.0-CURRENT after fixing handling of IOCTLs in the LinuxKPI. 1100109 299933 16 de maio de 2016 11.0-CURRENT after implementing more Linux device related functions in the LinuxKPI. 1100110 300207 19 de maio de 2016 11.0-CURRENT after adding support for managing Shingled Magnetic Recording (SMR) drives. 1100111 300303 20 de maio de 2016 11.0-CURRENT after removing brk and sbrk from arm64. 1100112 300539 23 de maio de 2016 11.0-CURRENT after adding bit_count to the bitstring3 API. 1100113 300701 26 de maio de 2016 11.0-CURRENT after disabling alignment faults on armv6. 1100114 300806 26 de maio de 2016 11.0-CURRENT after fixing crunchgen1 usage with MAKEOBJDIRPREFIX. 1100115 300982 30 de maio de 2016 11.0-CURRENT after adding an mbuf flag for M_HASHTYPE_. 1100116 301011 31 de maio de 2016 11.0-CURRENT after SHA-512t256 (rev 300903) and Skein (rev 300966) where added to libmd, libcrypt, the kernel, and ZFS (rev 301010). 1100117 301892 6 de junho de 2016 11.0-CURRENT after libpam was synced with stock 301602, bumping library version. 1100118 302071 21 de junho de 2016 11.0-CURRENT after breaking binary compatibility of struct disk 302069. 1100119 302150 23 de junho de 2016 11.0-CURRENT after switching geom_disk to using a pool mutex. 1100120 302153 23 de junho de 2016 11.0-CURRENT after adding spares to struct ifnet. 1100121 303979 12 de agosto de 2015 11-STABLE after releng/11.0 branched from 11-STABLE (rev 303975). 1100500 303979 12 de agosto de 2016 11.0-STABLE adding branched 303976. 1100501 304609 22 de agosto de 2016 11.0-STABLE after adding C++11 thread_local support. 1100502 304865 26 de agosto de 2016 11.0-STABLE after LC_*_MASK fix. 1100503 305733 12 de setembro de 2016 11.0-STABLE after resolving a deadlock between device_detach() and usbd_do_request_flags9. 1100504 307330 14 de outubro de 2016 11.0-STABLE after ZFS merges. 1100505 307590 19 de outubro de 2016 11.0-STABLE after struct fb_info change. 1100506 308048 28 de outubro de 2016 11.0-STABLE after installing header files required development with libzfs_core. 1100507 310120 15 de dezembro de 2016 11.0-STABLE after adding the ki_moretdname member to struct kinfo_proc and struct kinfo_proc32 to export the whole thread name to user-space utilities. 1100508 310618 26 de dezembro de 2016 11.0-STABLE after upgrading our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.1 release, and adding lld 3.9.1. 1100509 311186 3 de janeiro de 2017 11.0-STABLE after crunchgen1 META_MODE fix (rev r311185). 1100510 315312 15 de março de 2017 11.0-STABLE after MFC of fget_cap, getsock_cap, and related changes. 1100511 316423 2 de abril de 2017 11.0-STABLE after multiple MFCs updating clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release. 1100512 316498 4 de abril de 2017 11.0-STABLE after making CAM SIM lock optional (revs 315673, 315674). 1100513 318197 11 de maio de 2017 11.0-STABLE after merging the addition of the <dev/mmc/mmc_ioctl.h> header. 1100514 319279 31 de maio de 2017 11.0-STABLE after multiple MFCs of libpcap, WITHOUT_INET6, and a few other minor changes. 1101000 320486 30 de junho de 2017 releng/11.1 branched from stable/11. 1101001 320763 30 de junho de 2017 11.1-RC1 após de fundir a adição de flag MAP_GUARDmmap2. 1101500 320487 30 de junho de 2017 11-STABLE after releng/11.1 branched. 1101501 320666 5 de julho de 2017 11-STABLE after merging the MAP_GUARD mmap2 flag addition. 1101502 r321688 29 de julho de 2017 11-STABLE after merging the NFS client forced dismount support umount -N addition. 1101503 r323431 11 de setembro de 2017 11-STABLE after merging changes making the WRFSBASE instruction operational on amd64. 1101504 r324006 26 de setembro de 2017 11-STABLE after merging libm from head, which adds cacoshl3, cacosl3, casinhl3, casinl3, catanl3, catanhl3, sincos3, sincosf3, and sincosl3. 1101505 r324023 26 de setembro de 2017 11-STABLE after merging clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 release. 1101506 r325003 25 de outubro de 2017 11-STABLE after merging r324281, adding the value.u16 field to struct diocgattr_arg. 1101507 r328379 24 de janeiro de 2018 11-STABLE after merging r325028, fixing ptrace() to always clear the correct thread event when resuming. 1101508 r328386 24 de janeiro de 2018 11-STABLE after merging r316648, renaming smp_no_rendevous_barrier() to smp_no_rendezvous_barrier(). 1101509 r328653 1 de fevereiro de 2018 11-STABLE after an overwrite merge backport of the LinuxKPI from FreeBSD-head. 1101510 r329450 17 de fevereiro de 2018 11-STABLE after the cmpxchg() macro is now fully functional in the LinuxKPI. 1101511 r329981 25 de fevereiro de 2018 11-STABLE after concluding the recent LinuxKPI related updates. 1101512 r331219 19 de março de 2018 11-STABLE after merging retpoline support from the upstream llvm, clang and lld 5.0 branches. 1101513 r331838 31 de março de 2018 11-STABLE after merging clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, and several follow-up fixes. 1101514 r332089 5 de abril de 2018 11-STABLE after merging r328331, adding a new and incompatible interpretation of ${name}_limits in rc scripts. 1101515 r332363 10 de abril de 2018 11-STABLE after reverting r331880, removing the new and incompatible interpretation of ${name}_limits in rc scripts. 1101516 r334392 30 de maio de 2018 11-STABLE after dwatch1 touch-ups. 1102000 r334459 1 de junho de 2018 releng/11.2 branched from stable/11. 1102500 r334461 1 de junho de 2018 11-STABLE after releng/11.2 branched. 1102501 r335436 20 de junho de 2018 11-STABLE after LinuxKPI updates requiring recompilation of external kernel modules. 1102502 r338617 12 de setembro de 2018 11-STABLE after adding a socket option SO_TS_CLOCK and fixing recvmsg32() system call to properly down-convert layout of the 64-bit structures to match what 32-bit app(s) expect. 1102503 r338931 25 de setembro de 2018 11-STABLE after merging a TCP checksum fix to iflib9 and adding new media types to if_media.h 1102504 r340309 9 de novembro de 2018 11-STABLE after several MFCs: updating objcopy1 to properly handle little-endian MIPS64 object; correcting mips64el test to use ELF header; adding test for 64-bit ELF in _libelf_is_mips64el. 1102505 r342804 6 de janeiro de 2019 11-STABLE após o merge do fix para o comportamento do linux_destroy_dev () quando ainda existem arquivos abertos a partir da cdev que esta sendo destruída. 1102506 r344220 17 de fevereiro de 2019 11-STABLE depois de mesclar vários commits para o lualoader. + + + + 1102507 + r346296 + 16 de abril de 2019 + 11-STABLE after merging llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. + + + + 1103000 + r349026 + 14 de junho de 2019 + releng/11.3 branched from stable/11. + + + + 1103500 + r349027 + 14 de junho de 2019 + 11-STABLE after releng/11.3 branched.
Versões do FreeBSD 10 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 10 Valor Revisão Data Release 1000000 225757 26 de setembro de 2011 10.0-CURRENT 1000001 227070 4 de novembro de 2011 10-CURRENT after addition of the posix_fadvise2 system call. 1000002 228444 12 de dezembro de 2011 10-CURRENT after defining boolean true/false in sys/types.h, sizeof(bool) may have changed (rev 228444). 10-CURRENT after xlocale.h was introduced (rev 227753). 1000003 228571 16 de dezembro de 2011 10-CURRENT after major changes to carp4, changing size of struct in_aliasreq, struct in6_aliasreq (rev 228571) and straitening arguments check of SIOCAIFADDR (rev 228574). 1000004 229204 1 de janeiro de 2012 10-CURRENT after the removal of skpc() and the addition of memcchr9 (rev 229200). 1000005 230207 16 de janeiro de 2012 10-CURRENT after the removal of support for SIOCSIFADDR, SIOCSIFNETMASK, SIOCSIFBRDADDR, SIOCSIFDSTADDR ioctls. 1000006 230590 26 de janeiro de 2012 10-CURRENT after introduction of read capacity data asynchronous notification in the cam4 layer. 1000007 231025 5 de fevereiro de 2012 10-CURRENT after introduction of new tcp4 socket options: TCP_KEEPINIT, TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT. 1000008 231505 11 de fevereiro de 2012 10-CURRENT after introduction of the new extensible sysctl3 interface NET_RT_IFLISTL to query address lists. 1000009 232154 25 de fevereiro de 2012 10-CURRENT after import of libarchive 3.0.3 (rev 232153). 1000010 233757 31 de março de 2012 10-CURRENT after xlocale cleanup. 1000011 234355 16 de abril de 2012 10-CURRENT import of LLVM/Clang 3.1 trunk 154661 (rev 234353). 1000012 234924 2 de maio de 2012 10-CURRENT jemalloc import. 1000013 235788 22 de maio de 2012 10-CURRENT after byacc import. 1000014 237631 27 de junho de 2012 10-CURRENT after BSD sort becoming the default sort (rev 237629). 1000015 238405 12 de julho de 2012 10-CURRENT after import of OpenSSL 1.0.1c. (Não mudou) 238429 13 de julho de 2012 10-CURRENT after the fix for LLVM/Clang 3.1 regression. 1000016 239179 8 de agosto de 2012 10-CURRENT after KBI change in ucom4. 1000017 239214 8 de agosto de 2012 10-CURRENT after adding streams feature to the USB stack. 1000018 240233 8 de setembro de 2012 10-CURRENT after major rewrite of pf4. 1000019 241245 6 de outubro de 2012 10-CURRENT after pfil9 KBI/KPI changed to supply packets in net byte order to AF_INET filter hooks. 1000020 241610 16 de outubro de 2012 10-CURRENT after the network interface cloning KPI changed and struct if_clone becoming opaque. 1000021 241897 22 de outubro de 2012 10-CURRENT after removal of support for non-MPSAFE filesystems and addition of support for FUSEFS (rev 241519). 1000022 241913 22 de outubro de 2012 10-CURRENT after the entire IPv4 stack switched to network byte order for IP packet header storage. 1000023 242619 5 de novembro de 2012 10-CURRENT after jitter buffer in the common USB serial driver code, to temporarily store characters if the TTY buffer is full. Add flow stop and start signals when this happens. 1000024 242624 5 de novembro de 2012 10-CURRENT after clang was made the default compiler on i386 and amd64. 1000025 243443 17 de novembro de 2012 10-CURRENT after the sin6_scope_id member variable in struct sockaddr_in6 was changed to being filled by the kernel before passing the structure to the userland via sysctl or routing socket. This means the KAME-specific embedded scope id in sin6_addr.s6_addr[2] is always cleared in userland application. 1000026 245313 11 de janeiro de 2013 10-CURRENT after install gained the -N flag. May also be used to indicate the presence of nmtree. 1000027 246084 29 de janeiro de 2013 10-CURRENT after cat gained the -l flag (rev 246083). 1000028 246759 13 de fevereiro de 2013 10-CURRENT after USB moved to the driver structure requiring a rebuild of all USB modules. 1000029 247821 4 de março de 2013 10-CURRENT after the introduction of tickless callout facility which also changed the layout of struct callout (rev 247777). 1000030 248210 12 de março de 2013 10-CURRENT after KPI breakage introduced in the VM subsystem to support read/write locking (rev 248084). 1000031 249943 26 de abril de 2013 10-CURRENT after the dst parameter of the ifnet if_output method was changed to take const qualifier (rev 249925). 1000032 250163 1 de Maio de 2013 10-CURRENT after the introduction of the accept42 (rev 250154) and pipe22 (rev 250159) system calls. 1000033 250881 21 de maio de 2013 10-CURRENT after flex 2.5.37 import. 1000034 251294 3 de junho de 2013 10-CURRENT after the addition of these functions to libm: cacos3, cacosf3, cacosh3, cacoshf3, casin3, casinf3, casinh3, casinhf3, catan3, catanf3, catanh3, catanhf3, logl3, log2l3, log10l3, log1pl3, expm1l3. 1000035 251527 8 de junho de 2013 10-CURRENT after the introduction of the aio_mlock2 system call (rev 251526). 1000036 253049 9 de julho de 2013 10-CURRENT after the addition of a new function to the kernel GSSAPI module's function call interface. 1000037 253089 9 de julho de 2013 10-CURRENT after the migration of statistics structures to PCPU counters. Changed structures include: ahstat, arpstat, espstat, icmp6_ifstat, icmp6stat, in6_ifstat, ip6stat, ipcompstat, ipipstat, ipsecstat, mrt6stat, mrtstat, pfkeystat, pim6stat, pimstat, rip6stat, udpstat (rev 253081). 1000038 253396 16 de julho de 2013 10-CURRENT after making ARM EABI the default ABI on arm, armeb, armv6, and armv6eb architectures. 1000039 253549 22 de julho de 2013 10-CURRENT after CAM and mps4 driver scanning changes. 1000040 253638 24 de julho de 2013 10-CURRENT after addition of libusb pkgconf files. 1000041 253970 5 de agosto de 2013 10-CURRENT after change from time_second to time_uptime in PF_INET6. 1000042 254138 9 de agosto de 2013 10-CURRENT after VM subsystem change to unify soft and hard busy mechanisms. 1000043 254273 13 de agosto de 2013 10-CURRENT after WITH_ICONV is enabled by default. A new src.conf5 option, WITH_LIBICONV_COMPAT (disabled by default) adds libiconv_open to provide compatibility with the libiconv port. 1000044 254358 15 de agosto de 2013 10-CURRENT after libc.so conversion to an ld1 script (rev 251668). 1000045 254389 15 de agosto de 2013 10-CURRENT after devfs programming interface change by replacing the cdevsw flag D_UNMAPPED_IO with the struct cdev flag SI_UNMAPPED. 1000046 254537 19 de agosto de 2013 10-CURRENT after addition of M_PROTO[9-12] and removal of M_FRAG|M_FIRSTFRAG|M_LASTFRAG mbuf flags (rev 254524, 254526). 1000047 254627 21 de agosto de 2013 10-CURRENT after stat2 update to allow storing some Windows/DOS and CIFS file attributes as stat2 flags. 1000048 254672 22 de agosto de 2013 10-CURRENT after modification of structure xsctp_inpcb. 1000049 254760 24 de agosto de 2013 10-CURRENT after physio9 support for devices that do not function properly with split I/O, such as sa4. 1000050 254844 24 de agosto de 2013 10-CURRENT after modifications of structure mbuf (rev 254780, 254799, 254804, 254807 254842). 1000051 254887 25 de agosto de 2013 10-CURRENT after Radeon KMS driver import (rev 254885). 1000052 255180 3 de setembro de 2013 10-CURRENT after import of NetBSD libexecinfo is connected to the build. 1000053 255305 6 de setembro de 2013 10-CURRENT after API and ABI changes to the Capsicum framework. 1000054 255321 6 de setembro de 2013 10-CURRENT after gcc and libstdc++ are no longer built by default. 1000055 255449 6 de setembro de 2013 10-CURRENT after addition of MMAP_32BIT mmap2 flag (rev 255426). 1000100 259065 7 de dezembro de 2013 releng/10.0 branched from stable/10. 1000500 256283 10 de outubro de 2013 10-STABLE after branch from head/. 1000501 256916 22 de outubro de 2013 10-STABLE after addition of first-boot rc8 support. 1000502 258398 20 de novembro de 2013 10-STABLE after removal of iconv symbols from libc.so.7. 1000510 259067 7 de dezembro de 2013 releng/10.0 __FreeBSD_version update to prevent the value from going backwards. 1000700 259069 7 de dezembro de 2013 10-STABLE after releng/10.0 branch. 1000701 259447 15 de dezembro de 2013 10.0-STABLE after Heimdal encoding fix. 1000702 260135 31 de dezembro de 2013 10-STABLE after MAP_STACK fixes. 1000703 262801 5 de março de 2014 10-STABLE after upgrade of libc++ to 3.4 release. 1000704 262889 7 de março de 2014 10-STABLE after MFC of the vt4 driver (rev 262861). 1000705 263508 21 de março de 2014 10-STABLE after upgrade of llvm/clang to 3.4 release. 1000706 264214 6 de abril de 2014 10-STABLE after GCC support for __block definition. 1000707 264289 8 de abril de 2014 10-STABLE after FreeBSD-SA-14:06.openssl. 1000708 265122 30 de abril de 2014 10-STABLE after FreeBSD-SA-14:07.devfs, FreeBSD-SA-14:08.tcp, and FreeBSD-SA-14:09.openssl. 1000709 265946 13 de maio de 2014 10-STABLE after support for UDP-Lite protocol (RFC 3828). 1000710 267465 13 de junho de 2014 10-STABLE after changes to strcasecmp3, moving strcasecmp_l3 and strncasecmp_l3 from <string.h> to <strings.h> for POSIX 2008 compliance. 1000711 268442 8 de julho de 2014 10-STABLE after FreeBSD-SA-14:17.kmem (rev 268432). 1000712 269400 1 de agosto de 2014 10-STABLE after nfsd8 4.1 merge (rev 269398). 1000713 269484 3 de agosto de 2014 10-STABLE after regex3 library update to add > and < delimiters. 1000714 270174 3 de agosto de 2014 10-STABLE after SOCK_DGRAM bug fix (rev 269490). 1000715 271341 9 de setembro de 2014 10-STABLE after FreeBSD-SA-14:18 (rev 269686). 1000716 271686 16 de setembro de 2014 10-STABLE after FreeBSD-SA-14:19 (rev 271667). 1000717 271816 18 de setembro de 2014 10-STABLE after i915 HW context support. 1001000 272463 2 de outubro de 2014 10.1-RC1 after releng/10.1 branch. 1001500 272464 2 de outubro de 2014 10-STABLE after releng/10.1 branch. 1001501 273432 21 de outubro de 2014 10-STABLE after FreeBSD-SA-14:20, FreeBSD-SA-14:22, and FreeBSD-SA-14:23 (rev 273411). 1001502 274162 4 de novembro de 2014 10-STABLE after FreeBSD-SA-14:23, FreeBSD-SA-14:24, and FreeBSD-SA-14:25. 1001503 275040 25 de novembro de 2014 10-STABLE after merging new libraries/utilities (dpv1, dpv3, and figpar3) for data throughput visualization. 1001504 275742 13 de dezembro de 2014 10-STABLE after merging an important fix to the LLVM vectorizer, which could lead to buffer overruns in some cases. 1001505 276633 3 de janeiro de 2015 10-STABLE after merging some arm constants in 276312. 1001506 277087 12 de janeiro de 2015 10-STABLE after merging max table size update for yacc. 1001507 277790 27 de janeiro de 2015 10-STABLE after changes to the UDP tunneling callback to provide a context pointer and the source sockaddr. 1001508 278974 18 de fevereiro de 2015 10-STABLE after addition of the CDAI_TYPE_EXT_INQ request type. 1001509 279287 25 de fevereiro de 2015 10-STABLE after FreeBSD-EN-15:01.vt, FreeBSD-EN-15:02.openssl, FreeBSD-EN-15:03.freebsd-update, FreeBSD-SA-15:04.igmp, and FreeBSD-SA-15:05.bind. 1001510 279329 26 de fevereiro de 2015 10-STABLE after MFC of rev 278964. 1001511 280246 19 de março de 2015 10-STABLE after sys/capability.h is renamed to sys/capsicum.h (rev 280224/). 1001512 280438 24 de março de 2015 10-STABLE after addition of new mtio4, sa4 ioctls. 1001513 281955 24 de abril de 2015 10-STABLE after starting the process of removing the use of the deprecated "M_FLOWID" flag from the network code. 1001514 282275 30 de abril de 2015 10-STABLE after MFC of iconv3 fixes. 1001515 282781 11 de maio de 2015 10-STABLE after adding back M_FLOWID. 1001516 283341 24 de maio de 2015 10-STABLE after MFC of many USB things. 1001517 283950 3 de junho de 2015 10-STABLE after MFC of sound related things. 1001518 284204 10 de junho de 2015 10-STABLE after MFC of zfs vfs fixes (rev 284203). 1001519 284720 23 de junho de 2015 10-STABLE after reverting bumping MAXCPU on amd64. 1002000 285830 24 de julho de 2015 releng/10.2 branched from 10-STABLE. 1002500 285831 24 de julho de 2015 10-STABLE after releng/10.2 branched from 10-STABLE. 1002501 289005 8 de outubro de 2015 10-STABLE after merge of ZFS changes that affected the internal interface of zfeature_info structure (rev 288572). 1002502 291243 24 de novembro de 2015 10-STABLE after merge of dump device changes that affected the arguments of g_dev_setdumpdev()(rev 291215). 1002503 292224 14 de dezembro de 2015 10-STABLE after merge of changes to the internal interface between the nfsd.ko and nfscommon.ko modules, requiring them to be upgraded together (rev 292223). 1002504 292589 22 de dezembro de 2015 10-STABLE after merge of xz 5.2.2 merge (multithread support) (rev 292588). 1002505 292908 30 de dezembro de 2015 10-STABLE after merge of changes to pci4 (rev 292907). 1002506 293476 9 de janeiro de 2016 10-STABLE after merge of utimensat2 (rev 293473). 1002507 293610 9 de janeiro de 2016 10-STABLE after merge of changes to linux4 (rev 293477 through 293609 ). 1002508 293619 9 de janeiro de 2016 10-STABLE after merge of changes to figpar3 types/macros (rev 290275). 1002509 295107 1 de fevereiro de 2016 10-STABLE after merge of API change to dpv3. 1003000 296373 4 de março de 2016 releng/10.3 branched from 10-STABLE. 1003500 296374 4 de março de 2016 10-STABLE after releng/10.3 branched from 10-STABLE. 1003501 298299 19 de junho de 2016 10-STABLE after adding kdbcontrol's -P option (rev 298297). 1003502 299966 19 de junho de 2016 10-STABLE after libcrypto.so was made position independent. 1003503 300235 19 de junho de 2016 10-STABLE after allowing MK_ overrides (rev 300233). 1003504 302066 21 de junho de 2016 10-STABLE after MFC of filemon changes from 11-CURRENT. 1003505 302228 27 de junho de 2016 10-STABLE after converting sed to use REG_STARTEND, fixing a Mesa issue. 1003506 304611 22 de agosto de 2016 10-STABLE after adding C++11 thread_local support. 1003507 304864 26 de agosto de 2016 10-STABLE after LC_*_MASK fix. 1003508 305734 12 de setembro de 2016 10-STABLE after resolving a deadlock between device_detach() and usbd_do_request_flags9. 1003509 307331 14 de outubro de 2016 10-STABLE after ZFS merges. 1003510 308047 28 de outubro de 2016 10-STABLE after installing header files required development with libzfs_core. 1003511 310121 15 de dezembro de 2016 10-STABLE after exporting whole thread name in kinfo_proc (rev 309676). 1003512 315730 22 de março de 2017 10-STABLE after libmd changes (rev 314143). 1003513 316499 4 de abril de 2017 10-STABLE after making CAM SIM lock optional (revs 315673, 315674). 1003514 318198 11 de maio de 2017 10-STABLE after merging the addition of the <dev/mmc/mmc_ioctl.h> header. 1003515 321222 19 de julho de 2017 10-STABLE after adding C++14 sized deallocation functions to libc++. 1003516 321717 30 de julho de 2017 10-STABLE after merging the MAP_GUARD mmap2 flag addition. 1004000 323604 15 de setembro de 2017 releng/10.4 branched from 10-STABLE. 1004500 323605 15 de setembro de 2017 10-STABLE after releng/10.4 branched from 10-STABLE. 1004501 r328379 24 de janeiro de 2018 10-STABLE after merging r325028, fixing ptrace() to always clear the correct thread event when resuming.
Versões do FreeBSD 9 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 9 Valor Revisão Data Release 900000 196432 22 de agosto de 2009 9.0-CURRENT. 900001 197019 8 de setembro de 2009 9.0-CURRENT after importing x86emu, a software emulator for real mode x86 CPU from OpenBSD. 900002 197430 23 de setembro de 2009 9.0-CURRENT after implementing the EVFILT_USER kevent filter functionality. 900003 200039 2 de dezembro de 2009 9.0-CURRENT after addition of sigpause2 and PIE support in csu. 900004 200185 6 de dezembro de 2009 9.0-CURRENT after addition of libulog and its libutempter compatibility interface. 900005 200447 12 de dezembro de 2009 9.0-CURRENT after addition of sleepq_sleepcnt9, which can be used to query the number of waiters on a specific waiting queue. 900006 201513 4 de janeiro de 2010 9.0-CURRENT after change of the scandir3 and alphasort3 prototypes to conform to SUSv4. 900007 202219 13 de janeiro de 2010 9.0-CURRENT after the removal of utmp5 and the addition of utmpx (see getutxent3) for improved logging of user logins and system events. 900008 202722 20 de janeiro de 2010 9.0-CURRENT after the import of BSDL bc/dc and the deprecation of GNU bc/dc. 900009 203052 26 de janeiro de 2010 9.0-CURRENT after the addition of SIOCGIFDESCR and SIOCSIFDESCR ioctls to network interfaces. These ioctl can be used to manipulate interface description, as inspired by OpenBSD. 900010 205471 22 de março de 2010 9.0-CURRENT after the import of zlib 1.2.4. 900011 207410 24 de abril de 2010 9.0-CURRENT after adding soft-updates journalling. 900012 207842 10 de maio de 2010 9.0-CURRENT after adding liblzma, xz, xzdec, and lzmainfo. 900013 208486 24 de maio de 2010 9.0-CURRENT after bringing in USB fixes for linux4. 900014 208973 10 de junho de 2010 9.0-CURRENT after adding Clang. 900015 210390 22 de julho de 2010 9.0-CURRENT after the import of BSD grep. 900016 210565 28 de julho de 2010 9.0-CURRENT after adding mti_zone to struct malloc_type_internal. 900017 211701 23 de agosto de 2010 9.0-CURRENT after changing back default grep to GNU grep and adding WITH_BSD_GREP knob. 900018 211735 24 de agosto de 2010 9.0-CURRENT after the pthread_kill3 -generated signal is identified as SI_LWP in si_code. Previously, si_code was SI_USER. 900019 211937 28 de agosto de 2010 9.0-CURRENT after addition of the MAP_PREFAULT_READ flag to mmap2. 900020 212381 9 de setembro de 2010 9.0-CURRENT after adding drain functionality to sbufs, which also changed the layout of struct sbuf. 900021 212568 13 de setembro de 2010 9.0-CURRENT after DTrace has grown support for userland tracing. 900022 213395 2 de outubro de 2010 9.0-CURRENT after addition of the BSDL man utilities and retirement of GNU/GPL man utilities. 900023 213700 11 de outubro de 2010 9.0-CURRENT after updating xz to git 20101010 snapshot. 900024 215127 11 de novembro de 2010 9.0-CURRENT depois que libgcc.a foi trocado por libcompiler_rt.a. 900025 215166 12 de novembro de 2010 9.0-CURRENT after the introduction of the modularised congestion control. 900026 216088 30 de novembro de 2010 9.0-CURRENT after the introduction of Serial Management Protocol (SMP) passthrough and the XPT_SMP_IO and XPT_GDEV_ADVINFO CAM CCBs. 900027 216212 5 de dezembro de 2010 9.0-CURRENT after the addition of log2 to libm. 900028 216615 21 de dezembro de 2010 9.0-CURRENT after the addition of the Hhook (Helper Hook), Khelp (Kernel Helpers) and Object Specific Data (OSD) KPIs. 900029 216758 28 de dezembro de 2010 9.0-CURRENT after the modification of the TCP stack to allow Khelp modules to interact with it via helper hook points and store per-connection data in the TCP control block. 900030 217309 12 de janeiro de 2011 9.0-CURRENT after the update of libdialog to version 20100428. 900031 218414 7 de fevereiro de 2011 9.0-CURRENT after the addition of pthread_getthreadid_np3. 900032 218425 8 de fevereiro de 2011 9.0-CURRENT after the removal of the uio_yield prototype and symbol. 900033 218822 18 de fevereiro de 2011 9.0-CURRENT after the update of binutils to version 2.17.50. 900034 219406 8 de março de 2011 9.0-CURRENT after the struct sysvec (sv_schedtail) changes. 900035 220150 29 de março de 2011 9.0-CURRENT after the update of base gcc and libstdc++ to the last GPLv2 licensed revision. 900036 220770 18 de abril de 2011 9.0-CURRENT after the removal of libobjc and Objective-C support from the base system. 900037 221862 13 de maio de 2011 9.0-CURRENT after importing the libprocstat3 library and fuser1 utility to the base system. 900038 222167 22 de maio de 2011 9.0-CURRENT after adding a lock flag argument to VFS_FHTOVP9. 900039 223637 28 de junho de 2011 9.0-CURRENT after importing pf from OpenBSD 4.5. 900040 224217 19 de julho de 2011 Increase default MAXCPU for FreeBSD to 64 on amd64 and ia64 and to 128 for XLP (mips). 900041 224834 13 de agosto de 2011 9.0-CURRENT after the implementation of Capsicum capabilities; fget(9) gains a rights argument. 900042 225350 28 de agosto de 2011 Bump shared libraries' version numbers for libraries whose ABI has changed in preparation for 9.0. 900043 225350 2 de setembro de 2011 Add automatic detection of USB mass storage devices which do not support the no synchronize cache SCSI command. 900044 225469 10 de setembro de 2011 Re-factor auto-quirk. 9.0-RELEASE. 900045 229285 2 de janeiro de 2012 9-STABLE after MFC of true/false from 1000002. 900500 229318 2 de janeiro de 2012 9.0-STABLE. 900501 229723 6 de janeiro de 2012 9.0-STABLE after merging of addition of the posix_fadvise2 system call. 900502 230237 16 de janeiro de 2012 9.0-STABLE after merging gperf 3.0.3 900503 231768 15 de fevereiro de 2012 9.0-STABLE after introduction of the new extensible sysctl3 interface NET_RT_IFLISTL to query address lists. 900504 232728 3 de março de 2012 9.0-STABLE after changes related to mounting of filesystem inside a jail. 900505 232945 13 de março de 2012 9.0-STABLE after introduction of new tcp4 socket options: TCP_KEEPINIT, TCP_KEEPIDLE, TCP_KEEPINTVL, and TCP_KEEPCNT. 900506 235786 22 de maio de 2012 9.0-STABLE after introduction of the quick_exit function and related changes required for C++11. 901000 239082 5 de agosto de 2012 9.1-RELEASE. 901500 239081 6 de agosto de 2012 9.1-STABLE after branching releng/9.1 (RELENG_9_1). 901501 240659 11 de novembro de 2012 9.1-STABLE after LIST_PREV3 added to queue.h (rev 242893) and KBI change in USB serial devices. 901502 243656 28 de novembro de 2012 9.1-STABLE after USB serial jitter buffer requires rebuild of USB serial device modules. 901503 247090 21 de fevereiro de 2013 9.1-STABLE after USB moved to the driver structure requiring a rebuild of all USB modules. Also indicates the presence of nmtree. 901504 248338 15 de março de 2013 9.1-STABLE after install gained -l, -M, -N and related flags and cat gained the -l option. 901505 251687 13 de junho de 2013 9.1-STABLE after fixes in ctfmerge bootstrapping (rev 249243). 902001 253912 3 de agosto de 2013 releng/9.2 branched from stable/9. 902501 253913 2 de agosto de 2013 9.2-STABLE after creation of releng/9.2 branch. 902502 254938 26 de agosto de 2013 9.2-STABLE after inclusion of the PIM_RESCAN CAM path inquiry flag. 902503 254979 27 de agosto de 2013 9.2-STABLE after inclusion of the SI_UNMAPPED cdev flag. 902504 256917 22 de outubro de 2013 9.2-STABLE after inclusion of support for first boot rc8 scripts. 902505 259448 12 de dezembro de 2013 9.2-STABLE after Heimdal encoding fix. 902506 260136 31 de dezembro de 2013 9-STABLE after MAP_STACK fixes (rev 260082). 902507 262801 5 de março de 2014 9-STABLE after upgrade of libc++ to 3.4 release. 902508 263171 14 de março de 2014 9-STABLE after merge of the Radeon KMS driver (rev 263170). 902509 263509 21 de março de 2014 9-STABLE after upgrade of llvm/clang to 3.4 release. 902510 263818 27 de março de 2014 9-STABLE after merge of the vt4 driver. 902511 264289 27 de março de 2014 9-STABLE after FreeBSD-SA-14:06.openssl. 902512 265123 30 de abril de 2014 9-STABLE after FreeBSD-SA-14:08.tcp. 903000 267656 20 de junho de 2014 9-RC1 releng/9.3 branch. 903500 267657 20 de junho de 2014 9.3-STABLE releng/9.3 branch. 903501 268443 8 de julho de 2014 9-STABLE after FreeBSD-SA-14:17.kmem (rev 268433). 903502 270175 19 de agosto de 2014 9-STABLE after SOCK_DGRAM bug fix (rev 269789). 903503 271341 9 de setembro de 2014 9-STABLE after FreeBSD-SA-14:18 (rev 269687). 903504 271686 16 de setembro de 2014 9-STABLE after FreeBSD-SA-14:19 (rev 271668). 903505 273432 21 de outubro de 2014 9-STABLE after FreeBSD-SA-14:20, FreeBSD-SA-14:21, and FreeBSD-SA-14:22 (rev 273412). 903506 274162 4 de novembro de 2014 9-STABLE after FreeBSD-SA-14:23, FreeBSD-SA-14:24, and FreeBSD-SA-14:25. 903507 275742 13 de dezembro de 2014 9-STABLE after merging an important fix to the LLVM vectorizer, which could lead to buffer overruns in some cases. 903508 279287 25 de fevereiro de 2015 9-STABLE after FreeBSD-EN-15:01.vt, FreeBSD-EN-15:02.openssl, FreeBSD-EN-15:03.freebsd-update, FreeBSD-SA-15:04.igmp, and FreeBSD-SA-15:05.bind. 903509 296219 29 de fevereiro de 2016 9-STABLE after bumping the default value of compat.linux.osrelease to 2.6.18 to support the linux-c6-* ports out of the box. 903510 300236 19 de maio de 2016 9-STABLE after System Binary Interface (SBI) page was moved in latest version of Berkeley Boot Loader (BBL) due to code size increase in 300234. 903511 305735 12 de setembro de 2016 9-STABLE after resolving a deadlock between device_detach() and usbd_do_request_flags9.
Versões do FreeBSD 8 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 8 Valor Revisão Data Release 800000 172531 11 de outubro de 2007 8.0-CURRENT. Separating wide and single byte ctype. 800001 172688 16 de outubro de 2007 8.0-CURRENT after libpcap 0.9.8 and tcpdump 3.9.8 import. 800002 172841 21 de outubro de 2007 8.0-CURRENT after renaming kthread_create9 and friends to kproc_create9 etc. 800003 172932 24 de outubro de 2007 8.0-CURRENT after ABI backwards compatibility to the FreeBSD 4/5/6 versions of the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs was added, which required the ABI of the PCIOCGETCONF IOCTL to be broken again 800004 173573 12 de novembro de 2007 8.0-CURRENT after agp4 driver moved from src/sys/pci to src/sys/dev/agp 800005 174261 4 de dezembro de 2007 8.0-CURRENT after changes to the jumbo frame allocator (rev 174247). 800006 174399 7 de dezembro de 2007 8.0-CURRENT after the addition of callgraph capture functionality to hwpmc4. 800007 174901 25 de dezembro de 2007 8.0-CURRENT after kdb_enter() gains a "why" argument. 800008 174951 28 de dezembro de 2007 8.0-CURRENT after LK_EXCLUPGRADE option removal. 800009 175168 9 de janeiro de 2008 8.0-CURRENT after introduction of lockmgr_disown9 800010 175204 10 de janeiro de 2008 8.0-CURRENT after the vn_lock9 prototype change. 800011 175295 13 de janeiro de 2008 8.0-CURRENT after the VOP_LOCK9 and VOP_UNLOCK9 prototype changes. 800012 175487 19 de janeiro de 2008 8.0-CURRENT after introduction of lockmgr_recursed9, BUF_RECURSED9 and BUF_ISLOCKED9 and the removal of BUF_REFCNT(). 800013 175581 23 de janeiro de 2008 8.0-CURRENT after introduction of the ASCII encoding. 800014 175636 24 de janeiro de 2008 8.0-CURRENT after changing the prototype of lockmgr9 and removal of lockcount() and LOCKMGR_ASSERT(). 800015 175688 26 de janeiro de 2008 8.0-CURRENT after extending the types of the fts3 structures. 800016 175872 1 de fevereiro de 2008 8.0-CURRENT after adding an argument to MEXTADD9 800017 176015 6 de fevereiro de 2008 8.0-CURRENT after the introduction of LK_NODUP and LK_NOWITNESS options in the lockmgr9 space. 800018 176112 8 de fevereiro de 2008 8.0-CURRENT after the addition of m_collapse. 800019 176124 9 de fevereiro de 2008 8.0-CURRENT after the addition of current working directory, root directory, and jail directory support to the kern.proc.filedesc sysctl. 800020 176251 13 de fevereiro de 2008 8.0-CURRENT after introduction of lockmgr_assert9 and BUF_ASSERT functions. 800021 176321 15 de fevereiro de 2008 8.0-CURRENT after introduction of lockmgr_args9 and LK_INTERNAL flag removal. 800022 176556 (backed out) 8.0-CURRENT after changing the default system ar to BSD ar1. 800023 176560 25 de fevereiro de 2008 8.0-CURRENT after changing the prototypes of lockstatus9 and VOP_ISLOCKED9, more specifically retiring the struct thread argument. 800024 176709 1 de março de 2008 8.0-CURRENT after axing out the lockwaiters and BUF_LOCKWAITERS functions, changing the return value of brelvp from void to int and introducing new flags for lockinit9. 800025 176958 8 de março de 2008 8.0-CURRENT after adding F_DUP2FD command to fcntl2. 800026 177086 12 de março de 2008 8.0-CURRENT after changing the priority parameter to cv_broadcastpri such that 0 means no priority. 800027 177551 24 de março de 2008 8.0-CURRENT after changing the bpf monitoring ABI when zerocopy bpf buffers were added. 800028 177637 26 de março de 2008 8.0-CURRENT after adding l_sysid to struct flock. 800029 177688 28 de março de 2008 8.0-CURRENT after reintegration of the BUF_LOCKWAITERS function and the addition of lockmgr_waiters9. 800030 177844 1 de abril de 2008 8.0-CURRENT after the introduction of the rw_try_rlock9 and rw_try_wlock9 functions. 800031 177958 6 de abril de 2008 8.0-CURRENT after the introduction of the lockmgr_rw and lockmgr_args_rw functions. 800032 178006 8 de abril de 2008 8.0-CURRENT after the implementation of the openat and related syscalls, introduction of the O_EXEC flag for the open2, and providing the corresponding linux compatibility syscalls. 800033 178017 8 de abril de 2008 8.0-CURRENT after added write2 support for psm4 in native operation level. Now arbitrary commands can be written to /dev/psm%d and status can be read back from it. 800034 178051 10 de abril de 2008 8.0-CURRENT after introduction of the memrchr function. 800035 178256 16 de abril de 2008 8.0-CURRENT after introduction of the fdopendir function. 800036 178362 20 de abril de 2008 8.0-CURRENT after switchover of 802.11 wireless to multi-bss support (aka vaps). 800037 178892 9 de maio de 2008 8.0-CURRENT after addition of multi routing table support (aka setfib1, setfib2). 800038 179316 26 de maio de 2008 8.0-CURRENT after removal of netatm and ISDN4BSD. Also, the addition of the Compact C Type (CTF) tools. 800039 179784 14 de junho de 2008 8.0-CURRENT after removal of sgtty. 800040 180025 26 de junho de 2008 8.0-CURRENT with kernel NFS lockd client. 800041 180691 22 de julho de 2008 8.0-CURRENT after addition of arc4random_buf3 and arc4random_uniform3. 800042 181439 8 de agosto de 2008 8.0-CURRENT after addition of cpuctl4. 800043 181694 13 de agosto de 2008 8.0-CURRENT after changing bpf4 to use a single device node, instead of device cloning. 800044 181803 17 de agosto de 2008 8.0-CURRENT after the commit of the first step of the vimage project renaming global variables to be virtualized with a V_ prefix with macros to map them back to their global names. 800045 181905 20 de agosto de 2008 8.0-CURRENT after the integration of the MPSAFE TTY layer, including changes to various drivers and utilities that interact with it. 800046 182869 8 de setembro de 2008 8.0-CURRENT after the separation of the GDT per CPU on amd64 architecture. 800047 182905 10 de setembro de 2008 8.0-CURRENT after removal of VSVTX, VSGID and VSUID. 800048 183091 16 de setembro de 2008 8.0-CURRENT after converting the kernel NFS mount code to accept individual mount options in the nmount2 iovec, not just one big struct nfs_args. 800049 183114 17 de setembro de 2008 8.0-CURRENT after the removal of suser9 and suser_cred9. 800050 184099 20 de outubro de 2008 8.0-CURRENT after buffer cache API change. 800051 184205 23 de outubro de 2008 8.0-CURRENT after the removal of the MALLOC9 and FREE9 macros. 800052 184419 28 de outubro de 2008 8.0-CURRENT after the introduction of accmode_t and renaming of VOP_ACCESS 'a_mode' argument to 'a_accmode'. 800053 184555 2 de novembro de 2008 8.0-CURRENT after the prototype change of vfs_busy9 and the introduction of its MBF_NOWAIT and MBF_MNTLSTLOCK flags. 800054 185162 22 de novembro de 2008 8.0-CURRENT after the addition of buf_ring, memory barriers and ifnet functions to facilitate multiple hardware transmit queues for cards that support them, and a lockless ring-buffer implementation to enable drivers to more efficiently manage queuing of packets. 800055 185363 27 de novembro de 2008 8.0-CURRENT after the addition of Intel™ Core, Core2, and Atom support to hwpmc4. 800056 185435 29 de novembro de 2008 8.0-CURRENT after the introduction of multi-/no-IPv4/v6 jails. 800057 185522 1 de dezembro de 2008 8.0-CURRENT after the switch to the ath hal source code. 800058 185968 12 de dezembro de 2008 8.0-CURRENT after the introduction of the VOP_VPTOCNP operation. 800059 186119 15 de dezembro de 2008 8.0-CURRENT incorporates the new arp-v2 rewrite. 800060 186344 19 de dezembro de 2008 8.0-CURRENT after the addition of makefs. 800061 187289 15 de janeiro de 2009 8.0-CURRENT after TCP Appropriate Byte Counting. 800062 187830 28 de janeiro de 2009 8.0-CURRENT after removal of minor(), minor2unit(), unit2minor(), etc. 800063 188745 18 de fevereiro de 2009 8.0-CURRENT after GENERIC config change to use the USB2 stack, but also the addition of fdevname3. 800064 188946 23 de fevereiro de 2009 8.0-CURRENT after the USB2 stack is moved to and replaces dev/usb. 800065 189092 26 de fevereiro de 2009 8.0-CURRENT after the renaming of all functions in libmp3. 800066 189110 27 de fevereiro de 2009 8.0-CURRENT after changing USB devfs handling and layout. 800067 189136 28 de fevereiro de 2009 8.0-CURRENT after adding getdelim(), getline(), stpncpy(), strnlen(), wcsnlen(), wcscasecmp(), and wcsncasecmp(). 800068 189276 2 de março de 2009 8.0-CURRENT after renaming the ushub devclass to uhub. 800069 189585 9 de março de 2009 8.0-CURRENT after libusb20.so.1 was renamed to libusb.so.1. 800070 189592 9 de março de 2009 8.0-CURRENT after merging IGMPv3 and Source-Specific Multicast (SSM) to the IPv4 stack. 800071 189825 14 de março de 2009 8.0-CURRENT after gcc was patched to use C99 inline semantics in c99 and gnu99 mode. 800072 189853 15 de março de 2009 8.0-CURRENT after the IFF_NEEDSGIANT flag has been removed; non-MPSAFE network device drivers are no longer supported. 800073 190265 18 de março de 2009 8.0-CURRENT after the dynamic string token substitution has been implemented for rpath and needed paths. 800074 190373 24 de março de 2009 8.0-CURRENT after tcpdump 4.0.0 and libpcap 1.0.0 import. 800075 190787 6 de abril de 2009 8.0-CURRENT after layout of structs vnet_net, vnet_inet and vnet_ipfw has been changed. 800076 190866 9 de abril de 2009 8.0-CURRENT after adding delay profiles in dummynet. 800077 190914 14 de abril de 2009 8.0-CURRENT after removing VOP_LEASE() and vop_vector.vop_lease. 800078 191080 15 de abril de 2009 8.0-CURRENT after struct rt_weight fields have been added to struct rt_metrics and struct rt_metrics_lite, changing the layout of struct rt_metrics_lite. A bump to RTM_VERSION was made, but backed out. 800079 191117 15 de abril de 2009 8.0-CURRENT after struct llentry pointers are added to struct route and struct route_in6. 800080 191126 15 de abril de 2009 8.0-CURRENT after layout of struct inpcb has been changed. 800081 191267 19 de abril de 2009 8.0-CURRENT after the layout of struct malloc_type has been changed. 800082 191368 21 de abril de 2009 8.0-CURRENT after the layout of struct ifnet has changed, and with if_ref() and if_rele() ifnet refcounting. 800083 191389 22 de abril de 2009 8.0-CURRENT after the implementation of a low-level Bluetooth HCI API. 800084 191672 29 de abril de 2009 8.0-CURRENT after IPv6 SSM and MLDv2 changes. 800085 191688 30 de abril de 2009 8.0-CURRENT after enabling support for VIMAGE kernel builds with one active image. 800086 191910 8 de maio de 2009 8.0-CURRENT after adding support for input lines of arbitrarily length in patch1. 800087 191990 11 de maio de 2009 8.0-CURRENT after some VFS KPI changes. The thread argument has been removed from the FSD parts of the VFS. VFS_* functions do not need the context any more because it always refers to curthread. In some special cases, the old behavior is retained. 800088 192470 20 de maio de 2009 8.0-CURRENT after net80211 monitor mode changes. 800089 192649 23 de maio de 2009 8.0-CURRENT after adding UDP control block support. 800090 192669 23 de maio de 2009 8.0-CURRENT after virtualizing interface cloning. 800091 192895 27 de maio de 2009 8.0-CURRENT after adding hierarchical jails and removing global securelevel. 800092 193011 29 de maio de 2009 8.0-CURRENT after changing sx_init_flags() KPI. The SX_ADAPTIVESPIN is retired and a new SX_NOADAPTIVE flag is introduced to handle the reversed logic. 800093 193047 29 de maio de 2009 8.0-CURRENT after adding mnt_xflag to struct mount. 800094 193093 30 de maio de 2009 8.0-CURRENT after adding VOP_ACCESSX9. 800095 193096 30 de maio de 2009 8.0-CURRENT after changing the polling KPI. The polling handlers now return the number of packets processed. A new IFCAP_POLLING_NOCOUNT is also introduced to specify that the return value is not significant and the counting should be skipped. 800096 193219 1 de junho de 2009 8.0-CURRENT after updating to the new netisr implementation and after changing the way we store and access FIBs. 800097 193731 8 de junho de 2009 8.0-CURRENT after the introduction of vnet destructor hooks and infrastructure. (Não mudou) 194012 11 de junho de 2009 8.0-CURRENT after the introduction of netgraph outbound to inbound path call detection and queuing, which also changed the layout of struct thread. 800098 194210 14 de junho de 2009 8.0-CURRENT after OpenSSL 0.9.8k import. 800099 194675 22 de junho de 2009 8.0-CURRENT after NGROUPS update and moving route virtualization into its own VImage module. 800100 194920 24 de junho de 2009 8.0-CURRENT after SYSVIPC ABI change. 800101 195175 29 de junho de 2009 8.0-CURRENT after the removal of the /dev/net/* per-interface character devices. 800102 195634 12 de julho de 2009 8.0-CURRENT after padding was added to struct sackhint, struct tcpcb, and struct tcpstat. 800103 195654 13 de julho de 2009 8.0-CURRENT after replacing struct tcpopt with struct toeopt in the TOE driver interface to the TCP syncache. 800104 195699 14 de julho de 2009 8.0-CURRENT after the addition of the linker-set based per-vnet allocator. 800105 195767 19 de julho de 2009 8.0-CURRENT after version bump for all shared libraries that do not have symbol versioning turned on. 800106 195852 24 de julho de 2009 8.0-CURRENT after introduction of OBJT_SG VM object type. 800107 196037 2 de agosto de 2009 8.0-CURRENT after making the newbus subsystem Giant free by adding the newbus sxlock and 8.0-RELEASE. 800108 199627 21 de novembro de 2009 8.0-STABLE after implementing EVFILT_USER kevent filter. 800500 201749 7 de janeiro de 2010 8.0-STABLE after __FreeBSD_version bump to make pkg_add -r use packages-8-stable. 800501 202922 24 de janeiro de 2010 8.0-STABLE after change of the scandir3 and alphasort3 prototypes to conform to SUSv4. 800502 203299 31 de janeiro de 2010 8.0-STABLE after addition of sigpause2. 800503 204344 25 de fevereiro de 2010 8.0-STABLE after addition of SIOCGIFDESCR and SIOCSIFDESCR ioctls to network interfaces. These ioctl can be used to manipulate interface description, as inspired by OpenBSD. 800504 204546 1 de março de 2010 8.0-STABLE after MFC of importing x86emu, a software emulator for real mode x86 CPU from OpenBSD. 800505 208259 18 de maio de 2010 8.0-STABLE after MFC of adding liblzma, xz, xzdec, and lzmainfo. 801000 209150 14 de junho de 2010 8.1-RELEASE 801500 209146 14 de junho de 2010 8.1-STABLE after 8.1-RELEASE. 801501 214762 3 de novembro de 2010 8.1-STABLE after KBI change in struct sysentvec, and implementation of PL_FLAG_SCE/SCX/EXEC/SI and pl_siginfo for ptrace(PT_LWPINFO) . 802000 216639 22 de dezembro de 2010 8.2-RELEASE 802500 216654 22 de dezembro de 2010 8.2-STABLE after 8.2-RELEASE. 802501 219107 28 de fevereiro de 2011 8.2-STABLE after merging DTrace changes, including support for userland tracing. 802502 219324 6 de março de 2011 8.2-STABLE after merging log2 and log2f into libm. 802503 221275 1 de maio de 2011 8.2-STABLE after upgrade of the gcc to the last GPLv2 version from the FSF gcc-4_2-branch. 802504 222401 28 de maio de 2011 8.2-STABLE after introduction of the KPI and supporting infrastructure for modular congestion control. 802505 222406 28 de maio de 2011 8.2-STABLE after introduction of Hhook and Khelp KPIs. 802506 222408 28 de maio de 2011 8.2-STABLE after addition of OSD to struct tcpcb. 802507 222741 6 de junho de 2011 8.2-STABLE after ZFS v28 import. 802508 222846 8 de junho de 2011 8.2-STABLE after removal of the schedtail event handler and addition of the sv_schedtail method to struct sysvec. 802509 224017 14 de julho de 2011 8.2-STABLE after merging the SSSE3 support into binutils. 802510 224214 19 de julho de 2011 8.2-STABLE after addition of RFTSIGZMB flag for rfork2. 802511 225458 9 de setembro de 2011 8.2-STABLE after addition of automatic detection of USB mass storage devices which do not support the no synchronize cache SCSI command. 802512 225470 10 de setembro de 2011 8.2-STABLE after merging of re-factoring of auto-quirk. 802513 226763 25 de outubro de 2011 8.2-STABLE after merging of the MAP_PREFAULT_READ flag to mmap2. 802514 227573 16 de novembro de 2011 8.2-STABLE after merging of addition of posix_fallocate2 syscall. 802515 229725 6 de janeiro de 2012 8.2-STABLE after merging of addition of the posix_fadvise2 system call. 802516 230239 16 de janeiro de 2012 8.2-STABLE after merging gperf 3.0.3 802517 231769 15 de fevereiro de 2012 8.2-STABLE after introduction of the new extensible sysctl3 interface NET_RT_IFLISTL to query address lists. 803000 232446 3 de março de 2012 8.3-RELEASE. 803500 232439 3 de março de 2012 8.3-STABLE after branching releng/8.3 (RELENG_8_3). 803501 247091 21 de fevereiro de 2013 8.3-STABLE after MFC of two USB fixes (rev 246616 and 246759). 804000 248850 28 de março de 2013 8.4-RELEASE. 804500 248819 28 de março de 2013 8.4-STABLE after 8.4-RELEASE. 804501 259449 16 de dezembro de 2013 8.4-STABLE after MFC of upstream Heimdal encoding fix. 804502 265123 30 de abril de 2014 8.4-STABLE after FreeBSD-SA-14:08.tcp. 804503 268444 9 de julho de 2014 8.4-STABLE after FreeBSD-SA-14:17.kmem. 804504 271341 9 de setembro de 2014 8.4-STABLE after FreeBSD-SA-14:18 (rev 271305). 804505 271686 16 de setembro de 2014 8.4-STABLE after FreeBSD-SA-14:19 (rev 271668). 804506 273432 21 de outubro de 2014 8.4-STABLE depois de FreeBSD-SA-14:21 (rev 273413). 804507 274162 4 de novembro de 2014 8.4-STABLE after FreeBSD-SA-14:23, FreeBSD-SA-14:24, and FreeBSD-SA-14:25. 804508 279287 25 de fevereiro de 2015 8-STABLE after FreeBSD-EN-15:01.vt, FreeBSD-EN-15:02.openssl, FreeBSD-EN-15:03.freebsd-update, FreeBSD-SA-15:04.igmp, and FreeBSD-SA-15:05.bind. 804509 305736 12 de setembro de 2016 8-STABLE after resolving a deadlock between device_detach() and usbd_do_request_flags9.
Versões do FreeBSD 7 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 7 Valor Revisão Data Release 700000 147925 11 de julho de 2005 7.0-CURRENT. 700001 148341 23 de julho de 2005 7.0-CURRENT after bump of all shared library versions that had not been changed since RELENG_5. 700002 149039 13 de agosto de 2005 7.0-CURRENT after credential argument is added to dev_clone event handler. 700003 149470 25 de agosto de 2005 7.0-CURRENT after memmem3 is added to libc. 700004 151888 30 de outubro de 2005 7.0-CURRENT after solisten9 kernel arguments are modified to accept a backlog parameter. 700005 152296 11 de novembro de 2005 7.0-CURRENT after IFP2ENADDR() was changed to return a pointer to IF_LLADDR(). 700006 152315 11 de novembro de 2005 7.0-CURRENT after addition of if_addr member to struct ifnet and IFP2ENADDR() removal. 700007 153027 2 de dezembro de 2005 7.0-CURRENT after incorporating scripts from the local_startup directories into the base rcorder8. 700008 153107 5 de dezembro de 2005 7.0-CURRENT after removal of MNT_NODEV mount option. 700009 153519 19 de dezembro de 2005 7.0-CURRENT after ELF-64 type changes and symbol versioning. 700010 153579 20 de dezembro de 2005 7.0-CURRENT after addition of hostb and vgapci drivers, addition of pci_find_extcap(), and changing the AGP drivers to no longer map the aperture. 700011 153936 31 de dezembro de 2005 7.0-CURRENT after tv_sec was made time_t on all platforms but Alpha. 700012 154114 8 de janeiro de 2006 7.0-CURRENT after ldconfig_local_dirs change. 700013 154269 12 de janeiro de 2006 7.0-CURRENT after changes to /etc/rc.d/abi to support /compat/linux/etc/ld.so.cache being a symlink in a readonly filesystem. 700014 154863 26 de janeiro de 2006 7.0-CURRENT after pts import. 700015 157144 26 de março de 2006 7.0-CURRENT after the introduction of version 2 of hwpmc4's ABI. 700016 157962 22 de abril de 2006 7.0-CURRENT after addition of fcloseall3 to libc. 700017 158513 13 de maio de 2006 7.0-CURRENT after removal of ip6fw. 700018 160386 15 de julho de 2006 7.0-CURRENT after import of snd_emu10kx. 700019 160821 29 de julho de 2006 7.0-CURRENT after import of OpenSSL 0.9.8b. 700020 161931 3 de setembro de 2006 7.0-CURRENT after addition of bus_dma_get_tag function 700021 162023 4 de setembro de 2006 7.0-CURRENT after libpcap 0.9.4 and tcpdump 3.9.4 import. 700022 162170 9 de setembro de 2006 7.0-CURRENT after dlsym change to look for a requested symbol both in specified dso and its implicit dependencies. 700023 162588 23 de setembro de 2006 7.0-CURRENT after adding new sound IOCTLs for the OSSv4 mixer API. 700024 162919 28 de setembro de 2006 7.0-CURRENT after import of OpenSSL 0.9.8d. 700025 164190 11 de novembro de 2006 7.0-CURRENT after the addition of libelf. 700026 164614 26 de novembro de 2006 7.0-CURRENT after major changes on sound sysctls. 700027 164770 30 de novembro de 2006 7.0-CURRENT after the addition of Wi-Spy quirk. 700028 165242 15 de dezembro de 2006 7.0-CURRENT after the addition of sctp calls to libc 700029 166259 26 de janeiro de 2007 7.0-CURRENT after the GNU gzip1 implementation was replaced with a BSD licensed version ported from NetBSD. 700030 166549 7 de fevereiro de 2007 7.0-CURRENT after the removal of IPIP tunnel encapsulation (VIFF_TUNNEL) from the IPv4 multicast forwarding code. 700031 166907 23 de fevereiro de 2007 7.0-CURRENT after the modification of bus_setup_intr() (newbus). 700032 167165 2 de março de 2007 7.0-CURRENT after the inclusion of ipw4 and iwi4 firmware. 700033 167360 9 de março de 2007 7.0-CURRENT after the inclusion of ncurses wide character support. 700034 167684 19 de março de 2007 7.0-CURRENT after changes to how insmntque(), getnewvnode(), and vfs_hash_insert() work. 700035 167906 26 de março de 2007 7.0-CURRENT after addition of a notify mechanism for CPU frequency changes. 700036 168413 6 de abril de 2007 7.0-CURRENT after import of the ZFS filesystem. 700037 168504 8 de abril de 2007 7.0-CURRENT after addition of CAM 'SG' peripheral device, which implements a subset of Linux SCSI SG passthrough device API. 700038 169151 30 de abril de 2007 7.0-CURRENT after changing getenv3, putenv3, setenv3 and unsetenv3 to be POSIX conformant. 700039 169190 1 de maio de 2007 7.0-CURRENT after the changes in 700038 were backed out. 700040 169453 10 de maio de 2007 7.0-CURRENT after the addition of flopen3 to libutil. 700041 169526 13 de maio de 2007 7.0-CURRENT after enabling symbol versioning, and changing the default thread library to libthr. 700042 169758 19 de maio de 2007 7.0-CURRENT after the import of gcc 4.2.0. 700043 169830 21 de maio de 2007 7.0-CURRENT after bump of all shared library versions that had not been changed since RELENG_6. 700044 170395 7 de junho de 2007 7.0-CURRENT after changing the argument for vn_open()/VOP_OPEN() from file descriptor index to the struct file *. 700045 170510 10 de junho de 2007 7.0-CURRENT after changing pam_nologin8 to provide an account management function instead of an authentication function to the PAM framework. 700046 170530 11 de junho de 2007 7.0-CURRENT after updated 802.11 wireless support. 700047 170579 11 de junho de 2007 7.0-CURRENT after adding TCP LRO interface capabilities. 700048 170613 12 de junho de 2007 7.0-CURRENT after RFC 3678 API support added to the IPv4 stack. Legacy RFC 1724 behavior of the IP_MULTICAST_IF ioctl has now been removed; 0.0.0.0/8 may no longer be used to specify an interface index. Use struct ipmreqn instead. 700049 171175 3 de julho de 2007 7.0-CURRENT after importing pf from OpenBSD 4.1 (Não mudou) 171167 7.0-CURRENT after adding IPv6 support for FAST_IPSEC, deleting KAME IPSEC, and renaming FAST_IPSEC to IPSEC. 700050 171195 4 de julho de 2007 7.0-CURRENT after converting setenv/putenv/etc. calls from traditional BSD to POSIX. 700051 171211 4 de julho de 2007 7.0-CURRENT after adding new mmap/lseek/etc syscalls. 700052 171275 6 de julho de 2007 7.0-CURRENT after moving I4B headers to include/i4b. 700053 172394 30 de setembro de 2007 7.0-CURRENT after the addition of support for PCI domains 700054 172988 25 de outubro de 2007 7.0-STABLE after MFC of wide and single byte ctype separation. 700055 173104 28 de outubro de 2007 7.0-RELEASE, and 7.0-CURRENT after ABI backwards compatibility to the FreeBSD 4/5/6 versions of the PCIOCGETCONF, PCIOCREAD and PCIOCWRITE IOCTLs was MFCed, which required the ABI of the PCIOCGETCONF IOCTL to be broken again 700100 174864 22 de dezembro de 2007 7.0-STABLE after 7.0-RELEASE 700101 176111 8 de fevereiro de 2008 7.0-STABLE after the MFC of m_collapse(). 700102 177735 30 de março de 2008 7.0-STABLE after the MFC of kdb_enter_why(). 700103 178061 10 de abril de 2008 7.0-STABLE after adding l_sysid to struct flock. 700104 178108 11 de abril de 2008 7.0-STABLE after the MFC of procstat1. 700105 178120 11 de abril de 2008 7.0-STABLE after the MFC of umtx features. 700106 178225 15 de abril de 2008 7.0-STABLE after the MFC of write2 support to psm4. 700107 178353 20 de abril de 2008 7.0-STABLE after the MFC of F_DUP2FD command to fcntl2. 700108 178783 5 de maio de 2008 7.0-STABLE after some lockmgr9 changes, which makes it necessary to include sys/lock.h to use lockmgr9. 700109 179367 27 de maio de 2008 7.0-STABLE after MFC of the memrchr3 function. 700110 181328 5 de agosto de 2008 7.0-STABLE after MFC of kernel NFS lockd client. 700111 181940 20 de agosto de 2008 7.0-STABLE after addition of physically contiguous jumbo frame support. 700112 182294 27 de agosto de 2008 7.0-STABLE after MFC of kernel DTrace support. 701000 185315 25 de novembro de 2008 7.1-RELEASE 701100 185302 25 de novembro de 2008 7.1-STABLE after 7.1-RELEASE. 701101 187023 10 de janeiro de 2009 7.1-STABLE after strndup3 merge. 701102 187370 17 de janeiro de 2009 7.1-STABLE after cpuctl4 support added. 701103 188281 7 de fevereiro de 2009 7.1-STABLE after the merge of multi-/no-IPv4/v6 jails. 701104 188625 14 de fevereiro de 2009 7.1-STABLE after the store of the suspension owner in the struct mount, and introduction of vfs_susp_clean method into the struct vfsops. 701105 189740 12 de março de 2009 7.1-STABLE after the incompatible change to the kern.ipc.shmsegs sysctl to allow allocating larger SysV shared memory segments on 64bit architectures. 701106 189786 14 de março de 2009 7.1-STABLE after the merge of a fix for POSIX semaphore wait operations. 702000 191099 15 de abril de 2009 7.2-RELEASE 702100 191091 15 de abril de 2009 7.2-STABLE after 7.2-RELEASE. 702101 192149 15 de maio de 2009 7.2-STABLE after ichsmb4 was changed to use left-adjusted slave addressing to match other SMBus controller drivers. 702102 193020 28 de maio de 2009 7.2-STABLE after MFC of the fdopendir3 function. 702103 193638 06 de junho de 2009 7.2-STABLE after MFC of PmcTools. 702104 195694 14 de julho de 2009 7.2-STABLE after MFC of the closefrom2 system call. 702105 196006 31 de julho de 2009 7.2-STABLE after MFC of the SYSVIPC ABI change. 702106 197198 14 de setembro de 2009 7.2-STABLE after MFC of the x86 PAT enhancements and addition of d_mmap_single() and the scatter/gather list VM object type. 703000 203740 9 de fevereiro de 2010 7.3-RELEASE 703100 203742 9 de fevereiro de 2010 7.3-STABLE after 7.3-RELEASE. 704000 216647 22 de dezembro de 2010 7.4-RELEASE 704100 216658 22 de dezembro de 2010 7.4-STABLE after 7.4-RELEASE. 704101 221318 2 de maio de 2011 7.4-STABLE after the gcc MFC in rev 221317.
Versões do FreeBSD 6 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 6 Valor Revisão Data Release 600000 133921 18 de agosto de 2004 6.0-CURRENT 600001 134396 27 de agosto de 2004 6.0-CURRENT after permanently enabling PFIL_HOOKS in the kernel. 600002 134514 30 de agosto de 2004 6.0-CURRENT after initial addition of ifi_epoch to struct if_data. Backed out after a few days. Do not use this value. 600003 134933 8 de setembro de 2004 6.0-CURRENT after the re-addition of the ifi_epoch member of struct if_data. 600004 135920 29 de setembro de 2004 6.0-CURRENT after addition of the struct inpcb argument to the pfil API. 600005 136172 5 de outubro de 2004 6.0-CURRENT after addition of the "-d DESTDIR" argument to newsyslog. 600006 137192 4 de novembro de 2004 6.0-CURRENT after addition of glibc style strftime3 padding options. 600007 138760 12 de dezembro de 2004 6.0-CURRENT after addition of 802.11 framework updates. 600008 140809 25 de janeiro de 2005 6.0-CURRENT after changes to VOP_*VOBJECT() functions and introduction of MNTK_MPSAFE flag for Giantfree filesystems. 600009 141250 4 de fevereiro de 2005 6.0-CURRENT after addition of the cpufreq framework and drivers. 600010 141394 6 de fevereiro de 2005 6.0-CURRENT after importing OpenBSD's nc1. 600011 141727 12 de fevereiro de 2005 6.0-CURRENT after removing semblance of SVID2 matherr() support. 600012 141940 15 de fevereiro de 2005 6.0-CURRENT after increase of default thread stacks' size. 600013 142089 19 de fevereiro de 2005 6.0-CURRENT after fixes in <src/include/stdbool.h> and <src/sys/i386/include/_types.h> for using the GCC-compatibility of the Intel C/C++ compiler. 600014 142184 21 de fevereiro de 2005 6.0-CURRENT after EOVERFLOW checks in vswprintf3 fixed. 600015 142501 25 de fevereiro de 2005 6.0-CURRENT after changing the struct if_data member, ifi_epoch, from wall clock time to uptime. 600016 142582 26 de fevereiro de 2005 6.0-CURRENT after LC_CTYPE disk format changed. 600017 142683 27 de fevereiro de 2005 6.0-CURRENT after NLS catalogs disk format changed. 600018 142686 27 de fevereiro de 2005 6.0-CURRENT after LC_COLLATE disk format changed. 600019 142752 28 de fevereiro de 2005 Installation of acpica includes into /usr/include. 600020 143308 9 de março de 2005 Addition of MSG_NOSIGNAL flag to send2 API. 600021 143746 17 de março de 2005 Addition of fields to cdevsw 600022 143901 21 de março de 2005 Removed gtar from base system. 600023 144980 13 de abril de 2005 LOCAL_CREDS, LOCAL_CONNWAIT socket options added to unix4. 600024 145565 19 de abril de 2005 hwpmc4 and related tools added to 6.0-CURRENT. 600025 145565 26 de abril de 2005 struct icmphdr added to 6.0-CURRENT. 600026 145843 3 de maio de 2005 pf updated to 3.7. 600027 145966 6 de maio de 2005 Kernel libalias and ng_nat introduced. 600028 146191 13 de maio de 2005 POSIX ttyname_r3 made available through unistd.h and libc. 600029 146780 29 de maio de 2005 6.0-CURRENT after libpcap updated to v0.9.1 alpha 096. 600030 146988 5 de junho de 2005 6.0-CURRENT after importing NetBSD's if_bridge4. 600031 147256 10 de junho de 2005 6.0-CURRENT after struct ifnet was broken out of the driver softcs. 600032 147898 11 de julho de 2005 6.0-CURRENT after the import of libpcap v0.9.1. 600033 148388 25 de julho de 2005 6.0-STABLE after bump of all shared library versions that had not been changed since RELENG_5. 600034 149040 13 de agosto de 2005 6.0-STABLE after credential argument is added to dev_clone event handler. 6.0-RELEASE. 600100 151958 1 de novembro de 2005 6.0-STABLE after 6.0-RELEASE 600101 153601 21 de dezembro de 2005 6.0-STABLE after incorporating scripts from the local_startup directories into the base rcorder8. 600102 153912 30 de dezembro de 2005 6.0-STABLE after updating the ELF types and constants. 600103 154396 15 de janeiro de 2006 6.0-STABLE after MFC of pidfile3 API. 600104 154453 17 de janeiro de 2006 6.0-STABLE after MFC of ldconfig_local_dirs change. 600105 156019 26 de fevereiro de 2006 6.0-STABLE after NLS catalog support of csh1. 601000 158330 6 de maio de 2006 6.1-RELEASE 601100 158331 6 de maio de 2006 6.1-STABLE after 6.1-RELEASE. 601101 159861 22 de junho de 2006 6.1-STABLE after the import of csup. 601102 160253 11 de julho de 2006 6.1-STABLE after the iwi4 update. 601103 160429 17 de julho de 2006 6.1-STABLE after the resolver update to BIND9, and exposure of reentrant version of netdb functions. 601104 161098 8 de agosto de 2006 6.1-STABLE after DSO (dynamic shared objects) support has been enabled in OpenSSL. 601105 161900 2 de setembro de 2006 6.1-STABLE after 802.11 fixups changed the api for the IEEE80211_IOC_STA_INFO ioctl. 602000 164312 15 de novembro de 2006 6.2-RELEASE 602100 162329 15 de setembro de 2006 6.2-STABLE after 6.2-RELEASE. 602101 165122 12 de dezembro de 2006 6.2-STABLE after the addition of Wi-Spy quirk. 602102 165596 28 de dezembro de 2006 6.2-STABLE after pci_find_extcap() addition. 602103 166039 16 de janeiro de 2007 6.2-STABLE after MFC of dlsym change to look for a requested symbol both in specified dso and its implicit dependencies. 602104 166314 28 de janeiro de 2007 6.2-STABLE after MFC of ng_deflate4 and ng_pred14 netgraph nodes and new compression and encryption modes for ng_ppp4 node. 602105 166840 20 de fevereiro de 2007 6.2-STABLE after MFC of BSD licensed version of gzip1 ported from NetBSD. 602106 168133 31 de março de 2007 6.2-STABLE after MFC of PCI MSI and MSI-X support. 602107 168438 6 de abril de 2007 6.2-STABLE after MFC of ncurses 5.6 and wide character support. 602108 168611 11 de abril de 2007 6.2-STABLE after MFC of CAM 'SG' peripheral device, which implements a subset of Linux SCSI SG passthrough device API. 602109 168805 17 de abril de 2007 6.2-STABLE after MFC of readline 5.2 patchset 002. 602110 169222 2 de maio de 2007 6.2-STABLE after MFC of pmap_invalidate_cache(), pmap_change_attr(), pmap_mapbios(), pmap_mapdev_attr(), and pmap_unmapbios() for amd64 and i386. 602111 170556 11 de junho de 2007 6.2-STABLE after MFC of BOP_BDFLUSH and caused breakage of the filesystem modules KBI. 602112 172284 21 de setembro de 2007 6.2-STABLE after libutil(3) MFC's. 602113 172986 25 de outubro de 2007 6.2-STABLE after MFC of wide and single byte ctype separation. Newly compiled binary that references to ctype.h may require a new symbol, __mb_sb_limit, which is not available on older systems. 602114 173170 30 de outubro de 2007 6.2-STABLE after ctype ABI forward compatibility restored. 602115 173794 21 de novembro de 2007 6.2-STABLE after back out of wide and single byte ctype separation. 603000 173897 25 de novembro de 2007 6.3-RELEASE 603100 173891 25 de novembro de 2007 6.3-STABLE after 6.3-RELEASE. (Não mudou) 174434 7 de dezembro de 2007 6.3-STABLE after fixing multibyte type support in bit macro. 603102 178459 24 de abril de 2008 6.3-STABLE after adding l_sysid to struct flock. 603103 179367 27 de maio de 2008 6.3-STABLE after MFC of the memrchr3 function. 603104 179810 15 de junho de 2008 6.3-STABLE after MFC of support for :u variable modifier in make1. 604000 183583 4 de outubro de 2008 6.4-RELEASE 604100 183584 4 de outubro de 2008 6.4-STABLE after 6.4-RELEASE.
Versões do FreeBSD 5 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 5 Valor Revisão Data Release 500000 58009 13 de março de 2000 5.0-CURRENT 500001 59348 18 de abril de 2000 5.0-CURRENT after adding addition ELF header fields, and changing our ELF binary branding method. 500002 59906 2 de maio de 2000 5.0-CURRENT after kld metadata changes. 500003 60688 18 de maio de 2000 5.0-CURRENT after buf/bio changes. 500004 60936 26 de maio de 2000 5.0-CURRENT after binutils upgrade. 500005 61221 3 de junho de 2000 5.0-CURRENT after merging libxpg4 code into libc and after TASKQ interface introduction. 500006 61500 10 de junho de 2000 5.0-CURRENT after the addition of AGP interfaces. 500007 62235 29 de junho de 2000 5.0-CURRENT after Perl upgrade to 5.6.0 500008 62764 7 de julho de 2000 5.0-CURRENT after the update of KAME code to 2000/07 sources. 500009 63154 14 de julho de 2000 5.0-CURRENT after ether_ifattach() and ether_ifdetach() changes. 500010 63265 16 de julho de 2000 5.0-CURRENT after changing mtree defaults back to original variant, adding -L to follow symlinks. 500011 63459 18 de julho de 2000 5.0-CURRENT after kqueue API changed. 500012 65353 2 de setembro de 2000 5.0-CURRENT after setproctitle3 moved from libutil to libc. 500013 65671 10 de setembro de 2000 5.0-CURRENT after the first SMPng commit. 500014 70650 4 de janeiro de 2001 5.0-CURRENT after <sys/select.h> moved to <sys/selinfo.h>. 500015 70894 10 de janeiro de 2001 5.0-CURRENT after combining libgcc.a and libgcc_r.a, and associated GCC linkage changes. 500016 71583 24 de janeiro de 2001 5.0-CURRENT after change allowing libc and libc_r to be linked together, deprecating -pthread option. 500017 72650 18 de fevereiro de 2001 5.0-CURRENT after switch from struct ucred to struct xucred to stabilize kernel-exported API for mountd et al. 500018 72975 24 de fevereiro de 2001 5.0-CURRENT after addition of CPUTYPE make variable for controlling CPU-specific optimizations. 500019 77937 9 de junho de 2001 5.0-CURRENT after moving machine/ioctl_fd.h to sys/fdcio.h 500020 78304 15 de junho de 2001 5.0-CURRENT after locale names renaming. 500021 78632 22 de junho de 2001 5.0-CURRENT after Bzip2 import. Also signifies removal of S/Key. 500022 83435 12 de julho de 2001 5.0-CURRENT after SSE support. 500023 83435 14 de setembro de 2001 5.0-CURRENT after KSE Milestone 2. 500024 84324 1 de outubro de 2001 5.0-CURRENT after d_thread_t, and moving UUCP to ports. 500025 84481 4 de outubro de 2001 5.0-CURRENT after ABI change for descriptor and creds passing on 64 bit platforms. 500026 84710 9 de outubro de 2001 5.0-CURRENT after moving to XFree86 4 by default for package builds, and after the new libc strnstr() function was added. 500027 84743 10 de outubro de 2001 5.0-CURRENT after the new libc strcasestr() function was added. 500028 87879 14 de dezembro de 2001 5.0-CURRENT after the userland components of smbfs were imported. (Não mudou) 5.0-CURRENT after the new C99 specific-width integer types were added. 500029 89938 29 de janeiro de 2002 5.0-CURRENT after a change was made in the return value of sendfile2. 500030 90711 15 de fevereiro de 2002 5.0-CURRENT after the introduction of the type fflags_t, which is the appropriate size for file flags. 500031 91203 24 de fevereiro de 2002 5.0-CURRENT after the usb structure element rename. 500032 92453 16 de março de 2002 5.0-CURRENT after the introduction of Perl 5.6.1. 500033 93722 3 de abril de 2002 5.0-CURRENT after the sendmail_enable rc.conf5 variable was made to take the value NONE. 500034 95831 30 de abril de 2002 5.0-CURRENT after mtx_init() grew a third argument. 500035 96498 13 de maio de 2002 5.0-CURRENT with Gcc 3.1. 500036 96781 17 de maio de 2002 5.0-CURRENT without Perl in /usr/src 500037 97516 29 de maio de 2002 5.0-CURRENT after the addition of dlfunc3 500038 100591 24 de julho de 2002 5.0-CURRENT after the types of some struct sockbuf members were changed and the structure was reordered. 500039 102757 1 de setembro de 2002 5.0-CURRENT after GCC 3.2.1 import. Also after headers stopped using _BSD_FOO_T_ and started using _FOO_T_DECLARED. This value can also be used as a conservative estimate of the start of bzip21 package support. 500040 103675 20 de setembro de 2002 5.0-CURRENT after various changes to disk functions were made in the name of removing dependency on disklabel structure internals. 500041 104250 1 de outubro de 2002 5.0-CURRENT after the addition of getopt_long3 to libc. 500042 105178 15 de outubro de 2002 5.0-CURRENT after Binutils 2.13 upgrade, which included new FreeBSD emulation, vec, and output format. 500043 106289 1 de novembro de 2002 5.0-CURRENT after adding weak pthread_XXX stubs to libc, obsoleting libXThrStub.so. 5.0-RELEASE. 500100 109405 17 de janeiro de 2003 5.0-CURRENT after branching for RELENG_5_0 500101 111120 19 de fevereiro de 2003 <sys/dkstat.h> is empty. Do not include it. 500102 111482 25 de fevereiro de 2003 5.0-CURRENT after the d_mmap_t interface change. 500103 111540 26 de fevereiro de 2003 5.0-CURRENT after taskqueue_swi changed to run without Giant, and taskqueue_swi_giant added to run with Giant. 500104 111600 27 de fevereiro de 2003 cdevsw_add() and cdevsw_remove() no longer exists. Appearance of MAJOR_AUTO allocation facility. 500105 111864 4 de março de 2003 5.0-CURRENT after new cdevsw initialization method. 500106 112007 8 de março de 2003 devstat_add_entry() has been replaced by devstat_new_entry() 500107 112288 15 de março de 2003 Devstat interface change; see sys/sys/param.h 1.149 500108 112300 15 de março de 2003 Token-Ring interface changes. 500109 112571 25 de março de 2003 Addition of vm_paddr_t. 500110 112741 28 de março de 2003 5.0-CURRENT after realpath3 has been made thread-safe 500111 113273 9 de abril de 2003 5.0-CURRENT after usbhid3 has been synced with NetBSD 500112 113597 17 de abril de 2003 5.0-CURRENT after new NSS implementation and addition of POSIX.1 getpw*_r, getgr*_r functions 500113 114492 2 de maio de 2003 5.0-CURRENT after removal of the old rc system. 501000 115816 4 de junho de 2003 5.1-RELEASE. 501100 115710 2 de junho de 2003 5.1-CURRENT after branching for RELENG_5_1. 501101 117025 29 de junho de 2003 5.1-CURRENT after correcting the semantics of sigtimedwait2 and sigwaitinfo2. 501102 117191 3 de julho de 2003 5.1-CURRENT after adding the lockfunc and lockfuncarg fields to bus_dma_tag_create9. 501103 118241 31 de julho de 2003 5.1-CURRENT after GCC 3.3.1-pre 20030711 snapshot integration. 501104 118511 5 de agosto de 2003 5.1-CURRENT 3ware API changes to twe. 501105 119021 17 de agosto de 2003 5.1-CURRENT dynamically-linked /bin and /sbin support and movement of libraries to /lib. 501106 119881 8 de setembro de 2003 5.1-CURRENT after adding kernel support for Coda 6.x. 501107 120180 17 de setembro de 2003 5.1-CURRENT after 16550 UART constants moved from <dev/sio/sioreg.h> to <dev/ic/ns16550.h>. Also when libmap functionality was unconditionally supported by rtld. 501108 120386 23 de setembro de 2003 5.1-CURRENT after PFIL_HOOKS API update 501109 120503 27 de setembro de 2003 5.1-CURRENT after adding kiconv3 501110 120556 28 de setembro de 2003 5.1-CURRENT after changing default operations for open and close in cdevsw 501111 121125 16 de outubro de 2003 5.1-CURRENT after changed layout of cdevsw 501112 121129 16 de outubro de 2003 5.1-CURRENT after adding kobj multiple inheritance 501113 121816 31 de outubro de 2003 5.1-CURRENT after the if_xname change in struct ifnet 501114 122779 16 de novembro de 2003 5.1-CURRENT after changing /bin and /sbin to be dynamically linked 502000 123198 7 de dezembro de 2003 5.2-RELEASE 502010 126150 23 de fevereiro de 2004 5.2.1-RELEASE 502100 123196 7 de dezembro de 2003 5.2-CURRENT after branching for RELENG_5_2 502101 123677 19 de dezembro de 2003 5.2-CURRENT after __cxa_atexit/__cxa_finalize functions were added to libc. 502102 125236 30 de janeiro de 2004 5.2-CURRENT after change of default thread library from libc_r to libpthread. 502103 126083 21 de fevereiro de 2004 5.2-CURRENT after device driver API megapatch. 502104 126208 25 de fevereiro de 2004 5.2-CURRENT after getopt_long_only() addition. 502105 126644 5 de março de 2004 5.2-CURRENT after NULL is made into ((void *)0) for C, creating more warnings. 502106 126757 8 de março de 2004 5.2-CURRENT after pf is linked to the build and install. 502107 126819 10 de março de 2004 5.2-CURRENT after time_t is changed to a 64-bit value on sparc64. 502108 126891 12 de março de 2004 5.2-CURRENT after Intel C/C++ compiler support in some headers and execve2 changes to be more strictly conforming to POSIX. 502109 127312 22 de março de 2004 5.2-CURRENT after the introduction of the bus_alloc_resource_any API 502110 127475 27 de março de 2004 5.2-CURRENT after the addition of UTF-8 locales 502111 128144 11 de abril de 2004 5.2-CURRENT after the removal of the getvfsent3 API 502112 128182 13 de abril de 2004 5.2-CURRENT after the addition of the .warning directive for make. 502113 130057 4 de junho de 2004 5.2-CURRENT after ttyioctl() was made mandatory for serial drivers. 502114 130418 13 de junho de 2004 5.2-CURRENT after import of the ALTQ framework. 502115 130481 14 de junho de 2004 5.2-CURRENT after changing sema_timedwait9 to return 0 on success and a non-zero error code on failure. 502116 130585 16 de junho de 2004 5.2-CURRENT after changing kernel dev_t to be pointer to struct cdev *. 502117 130640 17 de junho de 2004 5.2-CURRENT after changing kernel udev_t to dev_t. 502118 130656 17 de junho de 2004 5.2-CURRENT after adding support for CLOCK_VIRTUAL and CLOCK_PROF to clock_gettime2 and clock_getres2. 502119 130934 22 de junho de 2004 5.2-CURRENT after changing network interface cloning overhaul. 502120 131429 2 de julho de 2004 5.2-CURRENT after the update of the package tools to revision 20040629. 502121 131883 9 de julho de 2004 5.2-CURRENT after marking Bluetooth code as non-i386 specific. 502122 131971 11 de julho de 2004 5.2-CURRENT after the introduction of the KDB debugger framework, the conversion of DDB into a backend and the introduction of the GDB backend. 502123 132025 12 de julho de 2004 5.2-CURRENT after change to make VFS_ROOT take a struct thread argument as does vflush. Struct kinfo_proc now has a user data pointer. The switch of the default X implementation to xorg was also made at this time. 502124 132597 24 de julho de 2004 5.2-CURRENT after the change to separate the way ports rc.d and legacy scripts are started. 502125 132726 28 de julho de 2004 5.2-CURRENT after the backout of the previous change. 502126 132914 31 de julho de 2004 5.2-CURRENT after the removal of kmem_alloc_pageable() and the import of gcc 3.4.2. 502127 132991 2 de agosto de 2004 5.2-CURRENT after changing the UMA kernel API to allow ctors/inits to fail. 502128 133306 8 de agosto de 2004 5.2-CURRENT after the change of the vfs_mount signature as well as global replacement of PRISON_ROOT with SUSER_ALLOWJAIL for the suser9 API. 503000 134189 23 de agosto de 2004 5.3-BETA/RC before the pfil API change 503001 135580 22 de setembro de 2004 5.3-RELEASE 503100 136595 16 de outubro de 2004 5.3-STABLE after branching for RELENG_5_3 503101 138459 3 de dezembro de 2004 5.3-STABLE after addition of glibc style strftime3 padding options. 503102 141788 13 de fevereiro de 2005 5.3-STABLE after OpenBSD's nc1 import MFC. 503103 142639 27 de fevereiro de 2005 5.4-PRERELEASE after the MFC of the fixes in <src/include/stdbool.h> and <src/sys/i386/include/_types.h> for using the GCC-compatibility of the Intel C/C++ compiler. 503104 142835 28 de fevereiro de 2005 5.4-PRERELEASE after the MFC of the change of ifi_epoch from wall clock time to uptime. 503105 143029 2 de março de 2005 5.4-PRERELEASE after the MFC of the fix of EOVERFLOW check in vswprintf3. 504000 144575 3 de abril de 2005 5.4-RELEASE 504100 144581 3 de abril de 2005 5.4-STABLE after branching for RELENG_5_4 504101 146105 11 de maio de 2005 5.4-STABLE after increasing the default thread stacksizes 504102 504101 24 de junho de 2005 5.4-STABLE after the addition of sha256 504103 150892 3 de outubro de 2005 5.4-STABLE after the MFC of if_bridge 504104 152370 13 de novembro de 2005 5.4-STABLE after the MFC of bsdiff and portsnap 504105 154464 17 de janeiro de 2006 5.4-STABLE after MFC of ldconfig_local_dirs change. 505000 158481 12 de maio de 2006 5.5-RELEASE 505100 158482 12 de maio de 2006 5.5-STABLE after branching for RELENG_5_5
Versões do FreeBSD 4 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 4 Valor Revisão Data Release 400000 43041 22 de janeiro de 1999 4.0-CURRENT after 3.4 branch 400001 44177 20 de fevereiro de 1999 4.0-CURRENT after change in dynamic linker handling 400002 44699 13 de março de 1999 4.0-CURRENT after C++ constructor/destructor order change 400003 45059 27 de março de 1999 4.0-CURRENT after functioning dladdr3 400004 45321 5 de abril de 1999 4.0-CURRENT after __deregister_frame_info dynamic linker bug fix (also 4.0-CURRENT after EGCS 1.1.2 integration) 400005 46113 27 de abril de 1999 4.0-CURRENT after suser9 API change (also 4.0-CURRENT after newbus) 400006 47640 31 de maio de 1999 4.0-CURRENT after cdevsw registration change 400007 47992 17 de junho de 1999 4.0-CURRENT after the addition of so_cred for socket level credentials 400008 48048 20 de junho de 1999 4.0-CURRENT after the addition of a poll syscall wrapper to libc_r 400009 48936 20 de julho de 1999 4.0-CURRENT after the change of the kernel's dev_t type to struct specinfo pointer 400010 51649 25 de setembro de 1999 4.0-CURRENT after fixing a hole in jail2 400011 51791 29 de setembro de 1999 4.0-CURRENT after the sigset_t datatype change 400012 53164 15 de novembro de 1999 4.0-CURRENT after the cutover to the GCC 2.95.2 compiler 400013 54123 4 de dezembro de 1999 4.0-CURRENT after adding pluggable linux-mode ioctl handlers 400014 56216 18 de janeiro de 2000 4.0-CURRENT after importing OpenSSL 400015 56700 27 de janeiro de 2000 4.0-CURRENT after the C++ ABI change in GCC 2.95.2 from -fvtable-thunks to -fno-vtable-thunks by default 400016 57529 27 de fevereiro de 2000 4.0-CURRENT after importing OpenSSH 400017 58005 13 de março de 2000 4.0-RELEASE 400018 58170 17 de março de 2000 4.0-STABLE after 4.0-RELEASE 400019 60047 5 de maio de 2000 4.0-STABLE after the introduction of delayed checksums. 400020 61262 4 de junho de 2000 4.0-STABLE after merging libxpg4 code into libc. 400021 62820 8 de julho de 2000 4.0-STABLE after upgrading Binutils to 2.10.0, ELF branding changes, and tcsh in the base system. 410000 63095 14 de julho de 2000 4.1-RELEASE 410001 64012 29 de julho de 2000 4.1-STABLE after 4.1-RELEASE 410002 65962 16 de setembro de 2000 4.1-STABLE after setproctitle3 moved from libutil to libc. 411000 66336 25 de setembro de 2000 4.1.1-RELEASE 411001 4.1.1-STABLE after 4.1.1-RELEASE 420000 68066 31 de outubro de 2000 4.2-RELEASE 420001 70895 10 de janeiro de 2001 4.2-STABLE after combining libgcc.a and libgcc_r.a, and associated GCC linkage changes. 430000 73800 6 de março de 2001 4.3-RELEASE 430001 76779 18 de maio de 2001 4.3-STABLE after wint_t introduction. 430002 80157 22 de julho de 2001 4.3-STABLE after PCI powerstate API merge. 440000 80923 1 de agosto de 2001 4.4-RELEASE 440001 85341 23 de outubro de 2001 4.4-STABLE after d_thread_t introduction. 440002 86038 4 de novembro de 2001 4.4-STABLE after mount structure changes (affects filesystem klds). 440003 88130 18 de dezembro de 2001 4.4-STABLE after the userland components of smbfs were imported. 450000 88271 20 de dezembro de 2001 4.5-RELEASE 450001 91203 24 de fevereiro de 2002 4.5-STABLE after the usb structure element rename. 450002 92151 12 de março de 2002 4.5-STABLE after locale changes. 450003 (Never created) 450004 94840 16 de abril de 2002 4.5-STABLE after the sendmail_enable rc.conf5 variable was made to take the value NONE. 450005 95555 27 de abril de 2002 4.5-STABLE after moving to XFree86 4 by default for package builds. 450006 95846 1 de maio de 2002 4.5-STABLE after accept filtering was fixed so that is no longer susceptible to an easy DoS. 460000 97923 21 de junho de 2002 4.6-RELEASE 460001 98730 21 de junho de 2002 4.6-STABLE sendfile2 fixed to comply with documentation, not to count any headers sent against the amount of data to be sent from the file. 460002 100366 19 de julho de 2002 4.6.2-RELEASE 460100 98857 26 de junho de 2002 4.6-STABLE 460101 98880 26 de junho de 2002 4.6-STABLE after MFC of `sed -i'. 460102 102759 1 de setembro de 2002 4.6-STABLE after MFC of many new pkg_install features from the HEAD. 470000 104655 8 de outubro de 2002 4.7-RELEASE 470100 104717 9 de outubro de 2002 4.7-STABLE 470101 106732 10 de novembro de 2002 Start generated __std{in,out,err}p references rather than __sF. This changes std{in,out,err} from a compile time expression to a runtime one. 470102 109753 23 de janeiro de 2003 4.7-STABLE after MFC of mbuf changes to replace m_aux mbufs by m_tag's 470103 110887 14 de fevereiro de 2003 4.7-STABLE gets OpenSSL 0.9.7 480000 112852 30 de março de 2003 4.8-RELEASE 480100 113107 5 de abril de 2003 4.8-STABLE 480101 115232 22 de maio de 2003 4.8-STABLE after realpath3 has been made thread-safe 480102 118737 10 de agosto de 2003 4.8-STABLE 3ware API changes to twe. 490000 121592 27 de outubro de 2003 4.9-RELEASE 490100 121593 27 de outubro de 2003 4.9-STABLE 490101 124264 8 de janeiro de 2004 4.9-STABLE after e_sid was added to struct kinfo_eproc. 490102 125417 4 de fevereiro de 2004 4.9-STABLE after MFC of libmap functionality for rtld. 491000 129700 25 de maio de 2004 4.10-RELEASE 491100 129918 1 de junho de 2004 4.10-STABLE 491101 133506 11 de agosto de 2004 4.10-STABLE after MFC of revision 20040629 of the package tools 491102 137786 16 de novembro de 2004 4.10-STABLE after VM fix dealing with unwiring of fictitious pages 492000 138960 17 de dezembro de 2004 4.11-RELEASE 492100 138959 17 de dezembro de 2004 4.11-STABLE 492101 157843 18 de abril de 2006 4.11-STABLE after adding libdata/ldconfig directories to mtree files.
Versões do FreeBSD 3 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 3 Valor Revisão Data Release 300000 22917 19 de fevereiro de 1996 3.0-CURRENT before mount2 change 300001 36283 24 de setembro de 1997 3.0-CURRENT after mount2 change 300002 36592 2 de junho de 1998 3.0-CURRENT after semctl2 change 300003 36735 7 de junho de 1998 3.0-CURRENT after ioctl arg changes 300004 38768 3 de setembro de 1998 3.0-CURRENT after ELF conversion 300005 40438 16 de outubro de 1998 3.0-RELEASE 300006 40445 16 de outubro de 1998 3.0-CURRENT after 3.0-RELEASE 300007 43042 22 de janeiro de 1999 3.0-STABLE after 3/4 branch 310000 43807 9 de fevereiro de 1999 3.1-RELEASE 310001 45060 27 de março de 1999 3.1-STABLE after 3.1-RELEASE 310002 45689 14 de abril de 1999 3.1-STABLE after C++ constructor/destructor order change 320000 3.2-RELEASE 320001 46742 8 de maio de 1999 3.2-RELEASE 320002 50563 29 de agosto de 1999 3.2-STABLE after binary-incompatible IPFW and socket changes 330000 50813 2 de setembro de 1999 3.3-RELEASE 330001 51328 16 de setembro de 1999 3.3-RELEASE 330002 53671 24 de novembro de 1999 3.3-STABLE after adding mkstemp3 to libc 340000 54166 5 de dezembro de 1999 3.4-RELEASE 340001 54730 17 de dezembro de 1999 3.4-RELEASE 350000 61876 20 de junho de 2000 3.5-RELEASE 350001 63043 12 de julho de 2000 3.5-STABLE
Versões do FreeBSD 2.2 Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 2.2 Valor Revisão Data Release 220000 22918 19 de fevereiro de 1997 2.2-RELEASE (Não mudou) 2.2.1-RELEASE (Não mudou) 2.2-STABLE after 2.2.1-RELEASE 221001 24941 15 de abril de 1997 2.2-STABLE after texinfo-3.9 221002 25325 30 de abril de 1997 2.2-STABLE after top 222000 25851 16 de maio de 1997 2.2.2-RELEASE 222001 25921 19 de maio de 1997 2.2-STABLE after 2.2.2-RELEASE 225000 30053 2 de outubro de 1997 2.2.5-RELEASE 225001 31300 20 de novembro de 1997 2.2-STABLE after 2.2.5-RELEASE 225002 32019 27 de dezembro de 1997 2.2-STABLE after ldconfig -R merge 226000 34445 24 de março de 1998 2.2.6-RELEASE 227000 37803 21 de julho de 1998 2.2.7-RELEASE 227001 37809 21 de julho de 1998 2.2-STABLE after 2.2.7-RELEASE 227002 39489 19 de setembro de 1998 2.2-STABLE after semctl2 change 228000 41403 29 de novembro de 1998 2.2.8-RELEASE 228001 41418 29 de novembro de 1998 2.2-STABLE after 2.2.8-RELEASE
Note que o 2.2-STABLE às vezes é identificado como 2.2.5-STABLE após o 2.2.5-RELEASE. O padrão costumava ser ano seguido do mês, mas decidimos mudá-lo para um sistema maior/menor mais simples a partir de 2.2. Isso aconteceu porque o desenvolvimento paralelo em várias branches inviabilizou a classificação dos lançamentos apenas por suas datas reais de lançamento. Não se preocupe com velhos -CURRENTs; eles estão listados aqui apenas para referência. FreeBSD 2 Antes das Versões 2.2-RELEASE Valores do <literal>__FreeBSD_version</literal> para o FreeBSD 2 de antes da 2.2-RELEASE Valor Revisão Data Release 119411 2.0-RELEASE 199501 7153 19 de março de 1995 2.1-CURRENT 199503 7310 24 de março de 1995 2.1-CURRENT 199504 7704 9 de abril de 1995 2.0.5-RELEASE 199508 10297 26 de agosto de 1995 2.2-CURRENT before 2.1 199511 12189 10 de novembro de 1995 2.1.0-RELEASE 199512 12196 10 de novembro de 1995 2.2-CURRENT before 2.1.5 199607 17067 10 de julho de 1996 2.1.5-RELEASE 199608 17127 12 de julho de 1996 2.2-CURRENT before 2.1.6 199612 19358 15 de novembro de 1996 2.1.6-RELEASE 199612 2.1.7-RELEASE
Index: head/pt_BR.ISO8859-1/books/porters-handbook/pt_BR.po =================================================================== --- head/pt_BR.ISO8859-1/books/porters-handbook/pt_BR.po (revision 53157) +++ head/pt_BR.ISO8859-1/books/porters-handbook/pt_BR.po (revision 53158) @@ -1,65572 +1,66925 @@ # $FreeBSD$ -# André Franciosi , 2018. #zanata -# Danilo G. Baio , 2018. #zanata -# Edson Brandi , 2018. #zanata -# Eduardo Elias El Assais , 2018. #zanata -# Lucas Andrade , 2018. #zanata -# Mauro Risonho de Paula Assumpção , 2018. #zanata -# Silvio Ap Silva , 2018. #zanata # Danilo G. Baio , 2019. #zanata # Edson Brandi , 2019. #zanata msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2019-04-21 12:57+0000\n" -"PO-Revision-Date: 2019-04-20 08:18+0000\n" -"Last-Translator: Copied by Zanata \n" +"POT-Creation-Date: 2019-06-15 19:04-0300\n" +"PO-Revision-Date: 2019-06-15 09:45+0000\n" +"Last-Translator: Danilo G. Baio \n" "Language-Team: \n" "Language: pt_BR\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: Zanata 4.6.2\n" "Plural-Forms: nplurals=2; plural=(n != 1)\n" #. Put one translator per line, in the form NAME , YEAR1, YEAR2 msgctxt "_" msgid "translator-credits" msgstr "" "Silvio Ap Silva, contato@kanazuchi.com, 2018\n" "Mauro Risonho de Paula Assumpção, mauro.risonho@gmail.com, 2018\n" "André Franciosi, andre@franciosi.org, 2018\n" "Edson Brandi, ebrandi@FreeBSD.org, 2018\n" "Danilo G. Baio, dbaio@FreeBSD.org, 2018\n" "Lucas Andrade, slucasandrade@protonmail.ch, 2018\n" "Eduardo Elias El Assais, eassais@gmail.com, 2018" #. (itstool) path: info/title #: book.translate.xml:39 msgid "FreeBSD Porter's Handbook" msgstr "FreeBSD Porter's Handbook" #. (itstool) path: authorgroup/author #: book.translate.xml:42 msgid "The FreeBSD Documentation Project" msgstr "Projeto de Documentação do FreeBSD" #. (itstool) path: info/pubdate #. (itstool) path: info/releaseinfo #: book.translate.xml:47 book.translate.xml:134 msgid "" "$FreeBSD: head/en_US.ISO8859-1/books/porters-handbook/book.xml 52824 " "2019-02-18 03:30:09Z linimon $" msgstr "" +"$FreeBSD: head/en_US.ISO8859-1/books/porters-handbook/book.xml 52824 " +"2019-02-18 03:30:09Z linimon $" #. (itstool) path: info/copyright #: book.translate.xml:49 msgid "" "2000 2001 2002 2003 " "2004 2005 2006 2007 " "2008 2009 2010 2011 " "2012 2013 2014 2015 " "2016 2017 2018 2019 " "The FreeBSD Documentation Project" msgstr "" "2000 2001 2002 2003 " "2004 2005 2006 2007 " "2008 2009 2010 2011 " "2012 2013 2014 2015 " "2016 2017 2018 2019 " "Projeto de Documentação do FreeBSD" #. (itstool) path: legalnotice/title #: book.translate.xml:76 msgid "Copyright" msgstr "Copyright" #. (itstool) path: legalnotice/para #: book.translate.xml:78 msgid "" "Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, " "HTML, PDF, PostScript, RTF and so forth) with or without modification, are " "permitted provided that the following conditions are met:" msgstr "" "Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, " "HTML, PDF, PostScript, RTF and so forth) with or without modification, are " "permitted provided that the following conditions are met:" #. (itstool) path: listitem/para #: book.translate.xml:85 msgid "" "Redistributions of source code (XML DocBook) must retain the above copyright " "notice, this list of conditions and the following disclaimer as the first " "lines of this file unmodified." msgstr "" "Redistributions of source code (XML DocBook) must retain the above copyright " "notice, this list of conditions and the following disclaimer as the first " "lines of this file unmodified." #. (itstool) path: listitem/para #: book.translate.xml:91 msgid "" "Redistributions in compiled form (transformed to other DTDs, converted to " "PDF, PostScript, RTF and other formats) must reproduce the above copyright " "notice, this list of conditions and the following disclaimer in the " "documentation and/or other materials provided with the distribution." msgstr "" "Redistributions in compiled form (transformed to other DTDs, converted to " "PDF, PostScript, RTF and other formats) must reproduce the above copyright " "notice, this list of conditions and the following disclaimer in the " "documentation and/or other materials provided with the distribution." #. (itstool) path: important/para #: book.translate.xml:100 msgid "" "THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT \"AS IS" "\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE " "IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE " "ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE " "LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR " "CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF " "SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS " "INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN " "CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) " "ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF " "THE POSSIBILITY OF SUCH DAMAGE." msgstr "" "THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT \"AS IS" "\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE " "IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE " "ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE " "LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR " "CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF " "SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS " "INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN " "CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) " "ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF " "THE POSSIBILITY OF SUCH DAMAGE." #. (itstool) path: legalnotice/para #: book.translate.xml:117 msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." #. (itstool) path: legalnotice/para #: book.translate.xml:119 msgid "" "UNIX is a registered trademark of The Open Group in the United States and " "other countries." msgstr "" "UNIX is a registered trademark of The Open Group in the United States and " "other countries." #. (itstool) path: legalnotice/para #: book.translate.xml:121 msgid "" "Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, " "Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or " "registered trademarks of Sun Microsystems, Inc. in the United States and " "other countries." msgstr "" "Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, " "Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or " "registered trademarks of Sun Microsystems, Inc. in the United States and " "other countries." #. (itstool) path: legalnotice/para #: book.translate.xml:126 msgid "" "Many of the designations used by manufacturers and sellers to distinguish " "their products are claimed as trademarks. Where those designations appear in " "this document, and the FreeBSD Project was aware of the trademark claim, the " "designations have been followed by the ™ or the ® symbol." msgstr "" "Many of the designations used by manufacturers and sellers to distinguish " "their products are claimed as trademarks. Where those designations appear in " "this document, and the FreeBSD Project was aware of the trademark claim, the " "designations have been followed by the ™ or the ® symbol." #. (itstool) path: chapter/title #. (itstool) path: sect2/title #. (itstool) path: sect1/title -#: book.translate.xml:145 book.translate.xml:11016 book.translate.xml:14893 -#: book.translate.xml:15383 book.translate.xml:19696 +#: book.translate.xml:145 book.translate.xml:11321 book.translate.xml:15198 +#: book.translate.xml:15688 book.translate.xml:20219 msgid "Introduction" msgstr "Introdução" #. (itstool) path: chapter/para #: book.translate.xml:147 msgid "" "The FreeBSD Ports Collection is the way almost everyone installs " "applications (\"ports\") on FreeBSD. Like everything else about FreeBSD, it " "is primarily a volunteer effort. It is important to keep this in mind when " "reading this document." msgstr "" "A Coleção de Ports do FreeBSD é a maneira como quase todo mundo instala " "aplicativos (\"ports\") no FreeBSD. Como tudo no FreeBSD, é principalmente " "um esforço voluntário. É importante ter isso em mente ao ler este documento." #. (itstool) path: chapter/para #: book.translate.xml:152 msgid "" "In FreeBSD, anyone may submit a new port, or volunteer to maintain an " "existing unmaintained port. No special commit privilege is needed." msgstr "" "No FreeBSD, qualquer um pode enviar um novo port ou ser voluntário para " "manter um port que esteja sem mantenedor. Nenhum privilégio de commit é " "necessário." #. (itstool) path: chapter/title #: book.translate.xml:167 msgid "Making a New Port" msgstr "Criando um Novo Port" #. (itstool) path: chapter/para #: book.translate.xml:169 msgid "Interested in making a new port, or upgrading existing ports? Great!" msgstr "" "Interessado em fazer um novo port ou atualizar os ports existentes? Ótimo!" #. (itstool) path: chapter/para #: book.translate.xml:172 msgid "" "What follows are some guidelines for creating a new port for FreeBSD. To " "upgrade an existing port, read this, then read ." msgstr "" "O que segue são algumas instruções para criar um novo port para o FreeBSD. " "Para atualizar um port existente, leia este documento e depois leia o ." #. (itstool) path: chapter/para #: book.translate.xml:176 msgid "" "When this document is not sufficiently detailed, refer to /usr/" "ports/Mk/bsd.port.mk, which is included by all port " "Makefiles. Even those not hacking Makefiles daily can gain much knowledge from it. Additionally, specific " "questions can be sent to the FreeBSD ports mailing list." msgstr "" "Quando este documento não for suficientemente detalhado, consulte /" "usr/ports/Mk/bsd.port.mk, que é incluído por todos os " "Makefiles dos ports. Mesmo aqueles que não estão " "hackeando os Makefiles diariamente podem ganhar muito " "conhecimento com isso. Além disso, perguntas específicas podem ser enviadas " "à Lista de discussão do ports do FreeBSD." #. (itstool) path: note/para #: book.translate.xml:184 msgid "" "Only a fraction of the variables (VAR) that can be overridden are mentioned in this document. Most (if " "not all) are documented at the start of /usr/ports/Mk/bsd.port.mk; the others probably ought to be. Note that this file uses a non-" "standard tab setting: Emacs and Vim will recognize the setting on loading the file. Both " "vi1 and ex1 can be set to use the " "correct value by typing :set tabstop=4 once the file has " "been loaded." msgstr "" "Apenas uma fração das variáveis ​​(VAR) que podem ser sobrepostas são mencionados neste documento. A " "maioria (se não todas) estão documentadas no início do /usr/ports/" "Mk/bsd.port.mk; as outras provavelmente deveriam estar também. " "Observe que esse arquivo usa uma configuração de tabulação não padrão: O " "Emacs e o Vim irão " "reconhecer a configuração ao carregar o arquivo. Ambos " "vi1 e ex1 podem ser configurados para usar o valor correto " "digitando :set tabstop=4 uma vez que o arquivo foi " "carregado." #. (itstool) path: chapter/para #: book.translate.xml:198 msgid "" "Looking for something easy to start with? Take a look at the list of requested ports " "and see if you can work on one (or more)." msgstr "" "Procurando algo fácil para começar? Dê uma olhada na lista de ports desejados e " "veja se você pode trabalhar em um (ou mais de um)." #. (itstool) path: chapter/title #: book.translate.xml:213 msgid "Quick Porting" msgstr "Port Rápido" #. (itstool) path: chapter/para #: book.translate.xml:215 msgid "" "This section describes how to quickly create a new port. For applications " "where this quick method is not adequate, the full Slow Porting process is described in ." msgstr "" "Esta seção descreve como criar rapidamente um novo port. Para aplicativos em " "que esse método rápido não for adequado, o processo Slow Porting está descrito no ." #. (itstool) path: chapter/para #: book.translate.xml:220 msgid "" "First, get the original tarball and put it into DISTDIR, " "which defaults to /usr/ports/distfiles." msgstr "" "Primeiro, obtenha o tarball original e coloque-o em DISTDIR, que por padrão é o diretório /usr/ports/distfiles." #. (itstool) path: note/para #: book.translate.xml:225 msgid "" "These steps assume that the software compiled out-of-the-box. In other " "words, absolutely no changes were required for the application to work on a " "FreeBSD system. If anything had to be changed, refer to ." msgstr "" "Estas etapas assumem que o software foi compilado de forma simples (out-of-" "the-box). Em outras palavras, não foi necessária absolutamente nenhuma " "mudança para o aplicativo funcionar em um sistema FreeBSD. Se alguma coisa " "teve que ser alterada, por favor consulte o ." #. (itstool) path: note/para #: book.translate.xml:232 msgid "" "It is recommended to set the DEVELOPER " "make1 variable in /etc/make.conf before getting " "into porting." msgstr "" "Recomenda-se definir a variável DEVELOPER do " "make1 em /etc/make.conf antes de começar o " "trabalho com os ports." #. (itstool) path: note/screen #: book.translate.xml:236 #, no-wrap msgid "# echo DEVELOPER=yes >> /etc/make.conf" msgstr "# echo DEVELOPER=yes >> /etc/make.conf" #. (itstool) path: note/para #: book.translate.xml:238 msgid "" "This setting enables the developer mode that displays " "deprecation warnings and activates some further quality checks on calling " "make." msgstr "" "Esta configuração habilita o modo de desenvolvedor que exibe " "avisos sobre a descontinuidade de comandos e ativa algumas verificações de " "qualidade adicionais nas execuções do comando make." #. (itstool) path: sect1/title #: book.translate.xml:244 msgid "Writing the Makefile" msgstr "Escrevendo o Makefile" #. (itstool) path: sect1/para #: book.translate.xml:246 msgid "" "The minimal Makefile would look something like this:" msgstr "O Makefile mínimo seria algo assim:" #. (itstool) path: sect1/programlisting #: book.translate.xml:249 #, no-wrap msgid "" "# $FreeBSD$\n" "\n" "PORTNAME=\toneko\n" "DISTVERSION=\t1.1b\n" "CATEGORIES=\tgames\n" "MASTER_SITES=\tftp://ftp.cs.columbia.edu/archives/X11R5/contrib/\n" "\n" "MAINTAINER=\tyouremail@example.com\n" "COMMENT=\tCat chasing a mouse all over the screen\n" "\n" ".include <bsd.port.mk>" msgstr "" "# $FreeBSD$\n" "\n" "PORTNAME=\toneko\n" "DISTVERSION=\t1.1b\n" "CATEGORIES=\tgames\n" "MASTER_SITES=\tftp://ftp.cs.columbia.edu/archives/X11R5/contrib/\n" "\n" "MAINTAINER=\tyouremail@example.com\n" "COMMENT=\tCat chasing a mouse all over the screen\n" "\n" ".include <bsd.port.mk>" #. (itstool) path: note/para #: book.translate.xml:262 msgid "" "In some cases, the Makefile of an existing port may " "contain additional lines in the header, such as the name of the port and the " "date it was created. This additional information has been declared obsolete, " "and is being phased out." msgstr "" "Em alguns casos, o Makefile de um port existente pode " "conter linhas adicionais no cabeçalho, como o nome do port e a data em que " "foi criado. Esta informação adicional foi declarada obsoleta e está sendo " "eliminada." #. (itstool) path: sect1/para #: book.translate.xml:269 msgid "" "Try to figure it out. Do not worry about the contents of the " "$FreeBSD$ line, it will be filled in automatically by " "Subversion when the port is imported to our main " "ports tree. A more detailed example is shown in the sample Makefile section." msgstr "" "Tente entender o exemplo. Não se preocupe com o conteúdo da linha " "$FreeBSD$, ela será preenchida automaticamente pelo " "Subversion quando o port for importado para nossa " "árvore de ports principais. Um exemplo mais detalhado é mostrado na seção " "exemplo de Makefile." #. (itstool) path: sect1/title #: book.translate.xml:280 msgid "Writing the Description Files" msgstr "Escrevendo os Arquivos de Descrição" #. (itstool) path: sect1/para #: book.translate.xml:282 msgid "" "There are two description files that are required for any port, whether they " "actually package or not. They are pkg-descr and " "pkg-plist. Their pkg- prefix " "distinguishes them from other files." msgstr "" "Existem dois arquivos de descrição que são necessários para qualquer port, " "independente deles estarem empacotados ou não. Eles são o pkg-" "descr e o pkg-plist. Seus prefixos " "pkg- distingue-os de outros arquivos." #. (itstool) path: sect2/title #: book.translate.xml:290 msgid "pkg-descr" msgstr "pkg-descr" #. (itstool) path: sect2/para #: book.translate.xml:292 msgid "" "This is a longer description of the port. One to a few paragraphs concisely " "explaining what the port does is sufficient." msgstr "" "Esta é uma descrição mais longa do port. Um ou alguns parágrafos que " "explicam o que o port faz é suficiente." #. (itstool) path: note/para #: book.translate.xml:297 msgid "" "This is not a manual or an in-depth description on how " "to use or compile the port! Please be careful when copying from " "the README or manpage. Too often they are " "not a concise description of the port or are in an awkward format. For " "example, manpages have justified spacing, which looks particularly bad with " "monospaced fonts." msgstr "" "Isto não é um manual ou uma descrição detalhada sobre " "como usar ou compilar o port! Por favor, tenha cuidado ao copiar " "do README ou manpage . Muitas vezes, eles " "não são uma descrição concisa do port ou estão em um formato estranho. Por " "exemplo, as páginas de manual têm espaçamento justificado, o que parece " "particularmente ruim com fontes monoespaçadas." #. (itstool) path: note/para #: book.translate.xml:306 msgid "" "On the other hand, the content of pkg-descr must be " "longer than the COMMENT line from the Makefile. It must explain in more depth what " "the port is all about." msgstr "" "Por outro lado, o conteúdo de pkg-descr deve ser mais " "longo que a linha COMMENT do Makefile. Ele deve explicar com mais profundidade o que é " "o port." #. (itstool) path: sect2/para #: book.translate.xml:312 msgid "" "A well-written pkg-descr describes the port completely " "enough that users would not have to consult the documentation or visit the " "website to understand what the software does, how it can be useful, or what " "particularly nice features it has. Mentioning certain requirements like a " "graphical toolkit, heavy dependencies, runtime environment, or " "implementation languages help users decide whether this port will work for " "them." msgstr "" "Um pkg-descr bem escrito descreve o port completamente " "o suficiente para que os usuários não precisem consultar a documentação ou " "visitar o site para entender o que o software faz, como ele pode ser útil ou " "quais recursos particularmente legais ​​ele possui. A menção de certos " "requisitos, como um kit de ferramentas gráfico, dependências pesadas, " "ambiente de runtime ou linguagens de implementação, ajuda os usuários a " "decidir se este port funcionará para eles." #. (itstool) path: sect2/para #: book.translate.xml:321 msgid "" "Include a URL to the official WWW homepage. Prepend one " "of the websites (pick the most common one) with WWW: " "(followed by single space) so that automated tools will work correctly. If " "the URI is the root of the website or directory, it must be terminated with " "a slash." msgstr "" "Inclua uma URL para a página Web oficial. Prefixe um " "dos sites (escolha o mais comum) com WWW: (seguido por um " "único espaço) para que as ferramentas automatizadas funcionem corretamente. " "Se a URI é a raiz do site ou diretório, ele deve ser terminado com uma barra." #. (itstool) path: note/para #: book.translate.xml:329 msgid "" "If the listed webpage for a port is not available, try to search the " "Internet first to see if the official site moved, was renamed, or is hosted " "elsewhere." msgstr "" "Se a página web listada para um port não estiver disponível, tente pesquisar " "na Internet primeiro para ver se o site oficial foi movido, foi renomeado ou " "se está hospedado em outro lugar." #. (itstool) path: sect2/para #: book.translate.xml:334 msgid "This example shows how pkg-descr looks:" msgstr "Este exemplo mostra como parece o pkg-descr:" #. (itstool) path: sect2/programlisting #: book.translate.xml:337 #, no-wrap msgid "" "This is a port of oneko, in which a cat chases a poor mouse all over\n" "the screen.\n" " :\n" "(etc.)\n" "\n" "WWW: http://www.oneko.org/" msgstr "" "This is a port of oneko, in which a cat chases a poor mouse all over\n" "the screen.\n" " :\n" "(etc.)\n" "\n" "WWW: http://www.oneko.org/" #. (itstool) path: sect2/title #: book.translate.xml:346 msgid "pkg-plist" msgstr "pkg-plist" #. (itstool) path: sect2/para #: book.translate.xml:348 msgid "" "This file lists all the files installed by the port. It is also called the " "packing list because the package is generated by packing the " "files listed here. The pathnames are relative to the installation prefix " "(usually /usr/local)." msgstr "" "Este arquivo lista todos os arquivos instalados pelo port. Ele também é " "chamado de packing list (lista de empacotamento) porque o " "pacote é gerado empacotando os arquivos listados aqui. Os pathnames são " "relativos ao prefixo de instalação (geralmente /usr/local)." #. (itstool) path: sect2/para #: book.translate.xml:354 msgid "Here is a small example:" msgstr "Aqui está um pequeno exemplo:" #. (itstool) path: sect2/programlisting #: book.translate.xml:356 #, no-wrap msgid "" "bin/oneko\n" "man/man1/oneko.1.gz\n" "lib/X11/app-defaults/Oneko\n" "lib/X11/oneko/cat1.xpm\n" "lib/X11/oneko/cat2.xpm\n" "lib/X11/oneko/mouse.xpm" msgstr "" "bin/oneko\n" "man/man1/oneko.1.gz\n" "lib/X11/app-defaults/Oneko\n" "lib/X11/oneko/cat1.xpm\n" "lib/X11/oneko/cat2.xpm\n" "lib/X11/oneko/mouse.xpm" #. (itstool) path: sect2/para #: book.translate.xml:363 msgid "" "Refer to the pkg-create8 manual page for " "details on the packing list." msgstr "" "Consulte a manpage do pkg-create8 para detalhes sobre a " "lista de empacotamento." #. (itstool) path: note/para #: book.translate.xml:367 msgid "" "It is recommended to keep all the filenames in this file sorted " "alphabetically. It will make verifying changes when upgrading the port much " "easier." msgstr "" "É recomendado manter todos os nomes de arquivos neste arquivo classificados " "em ordem alfabética. Isso tornará muito mais fácil verificar as alterações " "ao atualizar o port." #. (itstool) path: tip/para #: book.translate.xml:373 msgid "" "Creating a packing list manually can be a very tedious task. If the port " "installs a large numbers of files, creating the packing list automatically might save time." msgstr "" "Criar uma lista de packing manualmente pode ser uma tarefa muito tediosa. Se " "o port instalar um grande número de arquivos, criar a lista de empacotamento automaticamente pode economizar " "tempo." #. (itstool) path: sect2/para #: book.translate.xml:379 msgid "" "There is only one case when pkg-plist can be omitted " "from a port. If the port installs just a handful of files, list them in " "PLIST_FILES, within the port's Makefile. For instance, we could get along without pkg-plist in the above oneko port by adding these lines " "to the Makefile:" msgstr "" "Há apenas um caso em que o pkg-plist pode ser omitido " "de um port. Se o port instalar apenas alguns arquivos, liste-os em " "PLIST_FILES, dentro do Makefile do " "port. Por exemplo, poderíamos passar sem o pkg-plist no " "port oneko acima, adicionando estas linhas para no " "Makefile:" #. (itstool) path: sect2/programlisting #: book.translate.xml:388 #, no-wrap msgid "" "PLIST_FILES=\tbin/oneko \\\n" "\t\tman/man1/oneko.1.gz \\\n" "\t\tlib/X11/app-defaults/Oneko \\\n" "\t\tlib/X11/oneko/cat1.xpm \\\n" "\t\tlib/X11/oneko/cat2.xpm \\\n" "\t\tlib/X11/oneko/mouse.xpm" msgstr "" "PLIST_FILES=\tbin/oneko \\\n" "\t\tman/man1/oneko.1.gz \\\n" "\t\tlib/X11/app-defaults/Oneko \\\n" "\t\tlib/X11/oneko/cat1.xpm \\\n" "\t\tlib/X11/oneko/cat2.xpm \\\n" "\t\tlib/X11/oneko/mouse.xpm" #. (itstool) path: note/para #: book.translate.xml:396 msgid "" "Usage of PLIST_FILES should not be abused. When looking " "for the origin of a file, people usually try to grep through the pkg-plist files in the ports " "tree. Listing files in PLIST_FILES in the " "Makefile makes that search more difficult." msgstr "" "Uso de PLIST_FILES não deve ser abusado. Ao procurar pela " "origem de um arquivo, as pessoas geralmente tentam usar o grep através do pkg-plist nos arquivos na " "árvore de ports. Listar os arquivos na variável PLIST_FILES dentro do Makefile torna esta busca mais " "difícil." #. (itstool) path: tip/para #: book.translate.xml:406 msgid "" "If a port needs to create an empty directory, or creates directories outside " "of ${PREFIX} during installation, refer to for more information." msgstr "" "Se um port precisar criar um diretório vazio, ou criar diretórios fora do " "${PREFIX} durante a instalação, consulte para maiores informações." #. (itstool) path: tip/para #: book.translate.xml:413 msgid "" "As PLIST_FILES is a make1 variable, any entry " "with spaces must be quoted. For example, if using keywords described in " "pkg-create8 and , the entry " "must be quoted." msgstr "" "Como PLIST_FILES é uma variavel do " "make1, qualquer entrada com espaços deve ser envolvida por aspas. " "Por exemplo, se estiver usando palavras-chave descritas em " "pkg-create8 e na , a " "entrada deve ser citada." #. (itstool) path: tip/programlisting #: book.translate.xml:417 #, no-wrap msgid "PLIST_FILES=\t\"@sample ${ETCDIR}/oneko.conf.sample\"" msgstr "PLIST_FILES=\t\"@sample ${ETCDIR}/oneko.conf.sample\"" #. (itstool) path: sect2/para #: book.translate.xml:420 msgid "" "Later we will see how pkg-plist and " "PLIST_FILES can be used to fulfill more sophisticated tasks." msgstr "" "Mais tarde vamos ver como o pkg-plist e a " "PLIST_FILES podem ser utilizados para executar tarefas mais sofisticadas." #. (itstool) path: sect1/title #: book.translate.xml:428 msgid "Creating the Checksum File" msgstr "Criando o Arquivo Checksum" #. (itstool) path: sect1/para #: book.translate.xml:430 msgid "" "Just type make makesum. The ports framework will " "automatically generate distinfo. Do not try to generate " "the file manually." msgstr "" "Apenas digite make makesum. O framework do ports irá " "gerar automaticamente o distinfo. Não tente gerar o " "arquivo manualmente." #. (itstool) path: sect1/title #. (itstool) path: chapter/title -#: book.translate.xml:437 book.translate.xml:17930 +#: book.translate.xml:437 book.translate.xml:18453 msgid "Testing the Port" msgstr "Testando o Port" #. (itstool) path: sect1/para #: book.translate.xml:439 msgid "" "Make sure that the port rules do exactly what is desired, including " "packaging up the port. These are the important points to verify:" msgstr "" "Certifique-se de que as regras do port façam exatamente o que é desejado, " "incluindo o empacotamento do port. Estes são os pontos importantes a serem " "verificados:" #. (itstool) path: listitem/para #: book.translate.xml:445 msgid "" "pkg-plist does not contain anything not installed by " "the port." msgstr "" "pkg-plist não contém nada não instalado pelo port." #. (itstool) path: listitem/para #: book.translate.xml:450 msgid "" "pkg-plist contains everything that is installed by the " "port." msgstr "" "pkg-plist contém tudo o que é instalado pelo port." # auto translated by TM merge from project: RPM, version: master, DocId: rpm #. (itstool) path: para/buildtarget -#: book.translate.xml:456 book.translate.xml:742 book.translate.xml:6597 -#: book.translate.xml:6650 book.translate.xml:8875 book.translate.xml:9824 +#: book.translate.xml:456 book.translate.xml:742 book.translate.xml:6618 +#: book.translate.xml:6671 book.translate.xml:8896 book.translate.xml:9845 msgid "install" msgstr "install" #. (itstool) path: listitem/para #: book.translate.xml:455 msgid "" "The port can be installed using the <_:buildtarget-1/> target. This verifies " "that the install script works correctly." msgstr "" "O port pode ser instalado usando o target <_:buildtarget-1/>. Isso verifica " "se o script de instalação está funcionando corretamente." #. (itstool) path: para/buildtarget #: book.translate.xml:462 msgid "deinstall" msgstr "deinstall" #. (itstool) path: listitem/para #: book.translate.xml:461 msgid "" "The port can be deinstalled properly using the <_:buildtarget-1/> target. " "This verifies that the deinstall script works correctly." msgstr "" "O port pode ser desinstalado adequadamente usando o target <_:buildtarget-1/" ">. Isso verifica se o script de desinstalação funciona corretamente." #. (itstool) path: para/buildtarget #: book.translate.xml:468 book.translate.xml:664 book.translate.xml:665 -#: book.translate.xml:668 book.translate.xml:6739 +#: book.translate.xml:668 book.translate.xml:6760 msgid "fetch" msgstr "fetch" #. (itstool) path: listitem/para #: book.translate.xml:467 msgid "" "The port only has access to network resources during the <_:buildtarget-1/> " "target phase. This is important for package builders, such as ports-mgmt/poudriere." msgstr "" "O port só tem acesso aos recursos de rede durante a fase target <_:" "buildtarget-1/>. Isto é importante para os construtores de pacotes, tais " "como o ports-mgmt/poudriere." #. (itstool) path: listitem/para #: book.translate.xml:473 msgid "" "Make sure that make package can be run as a normal user " "(that is, not as root). If that " "fails, the software may need to be patched. See also and ." msgstr "" "Certifique-se de que o comando make package pode ser " "executado como um usuário normal (ou seja, não como root). Se isso falhar, talvez seja necessário " "corrigir o software. Veja a e também a " "." #. (itstool) path: procedure/title #: book.translate.xml:481 msgid "Recommended Test Ordering" msgstr "Ordem Recomendada de Teste" #. (itstool) path: step/para #: book.translate.xml:484 msgid "make stage" msgstr "make stage" #. (itstool) path: step/para #: book.translate.xml:488 msgid "make stage-qa" msgstr "make stage-qa" #. (itstool) path: step/para #: book.translate.xml:492 msgid "make package" msgstr "make package" #. (itstool) path: step/para #: book.translate.xml:496 msgid "make install" msgstr "make install" #. (itstool) path: step/para #: book.translate.xml:500 msgid "make deinstall" msgstr "make deinstall" #. (itstool) path: step/para #: book.translate.xml:504 msgid "make package (as user)" msgstr "make package (como usuário)" #. (itstool) path: sect1/para #: book.translate.xml:508 msgid "Make certain no warnings are shown in any of the stages." msgstr "Certifique-se de que nenhum aviso é exibido em nenhum dos estágios." #. (itstool) path: sect1/para #: book.translate.xml:511 msgid "" "Thorough automated testing can be done with ports-" "mgmt/poudriere from the Ports Collection, see for more information. It maintains jails where all of the steps shown above can be tested without affecting " "the state of the host system." msgstr "" "Testes automatizados completos podem ser feitos com o ports-mgmt/poudriere da coleção do Ports, veja a para maiores informações. Ele mantém jails onde todas as etapas mostradas acima podem ser testadas sem afetar " "o estado do sistema host." #. (itstool) path: sect1/title #: book.translate.xml:520 msgid "Checking the Port with portlint" msgstr "Verificando o Port com portlint" #. (itstool) path: sect1/para #: book.translate.xml:523 msgid "" "Please use portlint to see if the port conforms to our " "guidelines. The ports-mgmt/portlint program " "is part of the ports collection. In particular, check that the Makefile is in the right shape and the package is named appropriately." msgstr "" "Por favor, use o portlint para ver se o port está de " "acordo com as nossas diretrizes. O programa ports-" "mgmt/portlint faz parte da coleção de ports. Em particular, ele " "verifica se o Makefile está correto " "e se o pacote está nomeado " "apropriadamente." #. (itstool) path: important/para #: book.translate.xml:534 msgid "" "Do not blindly follow the output of portlint. It is a " "static lint tool and sometimes gets things wrong." msgstr "" "Não siga cegamente a saída do portlint. Ela é uma " "ferramenta de lint estática e às vezes comete erros." #. (itstool) path: sect1/title #: book.translate.xml:541 msgid "Submitting the New Port" msgstr "Enviando o Novo Port" #. (itstool) path: sect1/para #: book.translate.xml:543 msgid "" "Before submitting the new port, read the DOs " "and DON'Ts section." msgstr "" "Antes de enviar o novo port, leia a seção " "sobre o que fazer e o que não fazer." #. (itstool) path: sect1/para #: book.translate.xml:547 msgid "" "Once happy with the port, the only thing remaining is to put it in the main " "FreeBSD ports tree and make everybody else happy about it too." msgstr "" "Uma vez feliz com o port, a única coisa que resta é colocá-lo na árvore " "principal do FreeBSD e deixar todo mundo feliz também." #. (itstool) path: important/para #: book.translate.xml:552 msgid "" "We do not need the work directory or the " "pkgname.txz package, so delete them now." msgstr "" "Nós não precisamos do diretório work ou do pacote " "pkgname.tgz, então exclua-os agora." #. (itstool) path: sect1/para #: book.translate.xml:557 msgid "" "Next, either create a patch1, or a " "shar1 file. Assuming the port is called oneko and " "is in the games category." msgstr "" "Em seguida, crie um patch1 ou um arquivo " "shar1. Assumindo que o port é chamado oneko e " "está na categoria games." #. (itstool) path: example/title #: book.translate.xml:562 msgid "Creating a .diff for a New Port" msgstr "Criando um .diff para um Novo Port." #. (itstool) path: example/para #: book.translate.xml:565 msgid "" "Add all the files with svn add. cd to " "the base of the ports tree so full paths to the changed files are included " "in the diff, then generate the diff with svn diff. For " "example:" msgstr "" "Adicione todos os arquivos com svn add. Utilize o " "cd e vá para a base da árvore de ports, para que os " "caminhos completos dos arquivos alterados sejam incluídos no diff, então " "gere o diff com svn diff. Por exemplo:" #. (itstool) path: example/screen #: book.translate.xml:571 #, no-wrap msgid "" "% svn add .\n" "% cd ../..\n" "% svn diff games/oneko > oneko.diff" msgstr "" "% svn add .\n" "% cd ../..\n" "% svn diff games/oneko > oneko.diff" #. (itstool) path: important/para #: book.translate.xml:576 msgid "" "To make it easier for committers to apply the patch on their working copy of " "the ports tree, please generate the .diff from the base " "of your ports tree." msgstr "" "Para ser mais fácil para os committers aplicarem o patch em sua cópia de " "trabalho da árvore de ports, por favor, gere o .diff da " "base da sua árvore de ports." #. (itstool) path: example/title #: book.translate.xml:584 msgid "Creating a .shar for a New Port" msgstr "Criando um .shar para um Novo Port." #. (itstool) path: example/para #: book.translate.xml:587 msgid "" "cd to the directory above where the port directory is " "located, and use shar to create the archive:" msgstr "" "Utilize o cd e vá para o diretório acima de onde o " "diretório do port está localizado e use shar para criar o " "arquivo:" #. (itstool) path: example/screen #: book.translate.xml:591 #, no-wrap msgid "" "% cd ..\n" "% shar `find oneko` > oneko.shar" msgstr "" "% cd ..\n" "% shar `find oneko` > oneko.shar" #. (itstool) path: sect1/para #: book.translate.xml:595 msgid "" "Submit one of oneko.shar or oneko.diff with the bug " "submission form. Use product Ports & Packages, " "component Individual Port(s), and follow the guidelines shown " "there. Add a short description of the program to the Description field of " "the PR (perhaps a short version of COMMENT), and remember " "to add oneko.shar or oneko.diff as " "an attachment." msgstr "" "Envie um dos oneko.shar ou oneko.diff com o " "formulário de submissão de bugs. Use product Ports & " "Packages, component Individual Port(s) e siga as " "diretrizes mostradas lá. Adicione uma breve descrição do programa ao campo " "Description do PR (talvez uma versão curta do COMMENT), e " "lembre-se de adicionar o oneko.shar ou oneko." "diff como um anexo." #. (itstool) path: note/para #: book.translate.xml:607 msgid "" "Giving a good description in the summary of the problem report makes the " "work of port committers a lot easier. We prefer something like New " "port: category/portname short description of the port for new ports. Using this scheme makes it easier and faster to begin " "the work of committing the new port." msgstr "" "Dar uma boa descrição no resumo do relatório de problema facilita muito o " "trabalho dos commiters de ports. Preferimos algo como New port: " "category/portname " "breve descrição do port para novos ports. " "Usar este esquema torna mais fácil e rápido começar o trabalho para fazer o " "commit de um novo port." #. (itstool) path: sect1/para #: book.translate.xml:617 msgid "" "After submitting the port, please be patient. The time needed to include a " "new port in FreeBSD can vary from a few days to a few months. A simple " "search form of the Problem Report database can be searched at ." msgstr "" "Depois de enviar o port, por favor, seja paciente. O tempo necessário para " "incluir um novo port no FreeBSD pode variar de alguns dias até alguns meses. " "Um formulário simples de pesquisa no banco de dados do Relatório de " "Problemas está disponível em " #. (itstool) path: sect1/para #: book.translate.xml:622 msgid "" "To get a listing of open port PRs, " "select Open and Ports & Packages in the search form, then click [ Search ]." msgstr "" "Para obter uma listagem dos PRs abertos para os ports, selecione Open e " "Ports & Packages no formulário de pesquisa, clique " "em [ Search ]." #. (itstool) path: sect1/para #: book.translate.xml:627 msgid "" "After looking at the new port, we will reply if necessary, and commit it to " "the tree. The submitter's name will also be added to the list of Additional FreeBSD Contributors and other files." msgstr "" "Depois de analisar o novo port, nós responderemos se necessário, e iremos " "adicioná-lo a árvore. O nome do remetente também será adicionado à lista de " "Contribuidores Adicionais do FreeBSD e outros arquivos." #. (itstool) path: chapter/title #: book.translate.xml:642 msgid "Slow Porting" msgstr "Port Lento" #. (itstool) path: chapter/para #: book.translate.xml:644 msgid "" "Okay, so it was not that simple, and the port required some modifications to " "get it to work. In this section, we will explain, step by step, how to " "modify it to get it to work with the ports paradigm." msgstr "" "Certo, então não foi tão simples e o port precisou de algumas modificações " "para poder funcionar. Nesta seção, vamos explicar passo a passo como " "modificá-lo para que funcione com o paradigma do ports." #. (itstool) path: sect1/title #: book.translate.xml:650 msgid "How Things Work" msgstr "Como as Coisas Funcionam" #. (itstool) path: sect1/para #: book.translate.xml:652 msgid "" "First, this is the sequence of events which occurs when the user first types " "make in the port's directory. Having bsd.port." "mk in another window while reading this really helps to " "understand it." msgstr "" "Primeiro, esta é a sequência de eventos que ocorre quando o usuário executa " "make no diretório do port. Ter o bsd.port.mk aberto em outra janela enquanto lê esta seção realmente irá ajudar " "a entender melhor." #. (itstool) path: sect1/para #: book.translate.xml:658 msgid "" "But do not worry, not many people understand exactly how bsd.port." "mk is working... :-)" msgstr "" "Mas não se preocupe, não são muitas as pessoas que entendem exatamente como " "o bsd.port.mk funciona...:-)" #. (itstool) path: step/para #: book.translate.xml:664 msgid "" "The <_:buildtarget-1/> target is run. The <_:buildtarget-2/> target is " "responsible for making sure that the tarball exists locally in " "DISTDIR. If <_:buildtarget-3/> cannot find the required " "files in DISTDIR it will look up the URL " "MASTER_SITES, which is set in the Makefile, as well as " "our FTP mirrors where we put distfiles as backup. It will then attempt to " "fetch the named distribution file with FETCH, assuming " "that the requesting site has direct access to the Internet. If that " "succeeds, it will save the file in DISTDIR for future use " "and proceed." msgstr "" "O target <_:buildtarget-1/> é executado. O target <_:buildtarget-2/> é " "responsável por garantir que o tarball exista localmente em " "DISTDIR. Se o <_:buildtarget-3/> não puder encontrar os " "arquivos necessários no DISTDIR ele procurará a URL na " "variável MASTER_SITES, definida no Makefile, assim como " "nos nossos mirrors FTP nos quais colocamos os distfiles como backup. Em " "seguida, ele tentará buscar o arquivo de distribuição nomeado com " "FETCH, assumindo que o site solicitante tem acesso direto " "à Internet. Se isso for bem sucedido, ele salvará o arquivo em " "DISTDIR para uso futuro e continuará." #. (itstool) path: para/buildtarget #: book.translate.xml:681 book.translate.xml:782 book.translate.xml:788 -#: book.translate.xml:6717 book.translate.xml:6760 +#: book.translate.xml:6738 book.translate.xml:6781 msgid "extract" msgstr "extract" #. (itstool) path: step/para #: book.translate.xml:681 msgid "" "The <_:buildtarget-1/> target is run. It looks for the port's distribution " "file (typically a compressed tarball) in DISTDIR and " "unpacks it into a temporary subdirectory specified by WRKDIR (defaults to work)." msgstr "" "O target <_:buildtarget-1/> é executado. Ele procura pelo arquivo de " "distribuição do port (normalmente um tarball compactado) em " "DISTDIR e irá descompactá-lo em um subdiretório " "temporário especificado por WRKDIR (padrão é " "work) " #. (itstool) path: para/buildtarget -#: book.translate.xml:690 book.translate.xml:5011 book.translate.xml:6787 -#: book.translate.xml:24068 +#: book.translate.xml:690 book.translate.xml:5032 book.translate.xml:6808 +#: book.translate.xml:24592 msgid "patch" msgstr "patch" #. (itstool) path: step/para #: book.translate.xml:690 msgid "" "The <_:buildtarget-1/> target is run. First, any patches defined in " "PATCHFILES are applied. Second, if any patch files named " "patch-* are found in " "PATCHDIR (defaults to the files " "subdirectory), they are applied at this time in alphabetical order." msgstr "" "O target <_:buildtarget-1/> é executado. Primeiro, quaisquer patches " "definidos em PATCHFILES são aplicados. Segundo, se " "arquivos de patch nomeados patch-* forem encontrados em PATCHDIR (padrão para o " "subdiretório files), eles serão aplicados neste momento " "em ordem alfabética." #. (itstool) path: para/buildtarget #. (itstool) path: entry/buildtarget -#: book.translate.xml:700 book.translate.xml:783 book.translate.xml:5012 -#: book.translate.xml:11515 book.translate.xml:22551 book.translate.xml:22553 +#: book.translate.xml:700 book.translate.xml:783 book.translate.xml:5033 +#: book.translate.xml:11820 book.translate.xml:23075 book.translate.xml:23077 msgid "configure" msgstr "configure" #. (itstool) path: step/para #: book.translate.xml:700 msgid "" "The <_:buildtarget-1/> target is run. This can do any one of many different " "things." msgstr "" "O target <_:buildtarget-1/> é executado. Ele pode fazer qualquer uma de " "muitas coisas diferentes." #. (itstool) path: listitem/para #: book.translate.xml:705 msgid "If it exists, scripts/configure is run." msgstr "Se existir, scripts/configure é executado." #. (itstool) path: listitem/para #: book.translate.xml:710 msgid "" "If HAS_CONFIGURE or GNU_CONFIGURE is " "set, WRKSRC/configure is run." msgstr "" "E se HAS_CONFIGURE ou GNU_CONFIGURE " "está definido, WRKSRC/configure é executado." #. (itstool) path: para/buildtarget -#: book.translate.xml:718 book.translate.xml:5013 book.translate.xml:6596 -#: book.translate.xml:24070 +#: book.translate.xml:718 book.translate.xml:5034 book.translate.xml:6617 +#: book.translate.xml:24594 msgid "build" msgstr "build" #. (itstool) path: step/para #: book.translate.xml:718 msgid "" "The <_:buildtarget-1/> target is run. This is responsible for descending " "into the port's private working directory (WRKSRC) and " "building it." msgstr "" "O target <_:buildtarget-1/> é executado. Ele é responsável por mudar para o " "diretório de trabalho privado do port (WRKSRC) e compila-" "lo." #. (itstool) path: para/buildtarget #: book.translate.xml:725 book.translate.xml:737 msgid "stage" msgstr "stage" #. (itstool) path: step/para #: book.translate.xml:725 msgid "" "The <_:buildtarget-1/> target is run. This puts the final set of built files " "into a temporary directory (STAGEDIR, see ). The hierarchy of this directory mirrors that of the system " "on which the package will be installed." msgstr "" "O target <_:buildtarget-1/> é executado. Este coloca o conjunto final de " "arquivos construídos em um diretório temporário (STAGEDIR, Veja ). A hierarquia deste diretório " "espelha a do sistema no qual o pacote será instalado." # auto translated by TM merge from project: Hammer CLI Foreman, version: master, DocId: hammer-cli-foreman #. (itstool) path: para/buildtarget #: book.translate.xml:734 book.translate.xml:744 msgid "package" msgstr "package" #. (itstool) path: step/para #: book.translate.xml:734 msgid "" "The <_:buildtarget-1/> target is run. This creates a package using the files " "from the temporary directory created during the <_:buildtarget-2/> target " "and the port's pkg-plist." msgstr "" "O target <_:buildtarget-1/> é executado. Ele cria um pacote usando os " "arquivos do diretório temporário criado durante o target <_:buildtarget-2/> " "e o pkg-plist do port." #. (itstool) path: step/para #: book.translate.xml:742 msgid "" "The <_:buildtarget-1/> target is run. This installs the package created " "during the <_:buildtarget-2/> target into the host system." msgstr "" "O target <_:buildtarget-1/> é executado. Este instala o pacote criado " "durante o target <_:buildtarget-2/> no host." #. (itstool) path: para/buildtarget #: book.translate.xml:751 msgid "pre-something" msgstr "pre-something" #. (itstool) path: para/buildtarget #: book.translate.xml:753 msgid "post-something" msgstr "post-something" #. (itstool) path: sect1/para #: book.translate.xml:749 msgid "" "The above are the default actions. In addition, define targets <_:" "buildtarget-1/> or <_:buildtarget-2/>, or put scripts with those names, in " "the scripts subdirectory, and they will be run before " "or after the default actions are done." msgstr "" "As ações acima são padrão. Além disso, defina os targets <_:buildtarget-1/> " "ou <_:buildtarget-2/>, ou insira scripts com esses nomes no subdiretório " "scripts, e eles serão executados antes ou depois das " "ações padrão serem executadas." #. (itstool) path: para/buildtarget #: book.translate.xml:759 book.translate.xml:763 book.translate.xml:976 -#: book.translate.xml:3864 book.translate.xml:4242 book.translate.xml:8588 +#: book.translate.xml:3858 book.translate.xml:4246 book.translate.xml:8609 msgid "post-extract" msgstr "post-extract" #. (itstool) path: sect1/para #: book.translate.xml:758 msgid "" "For example, if there is a <_:buildtarget-1/> target defined in the " "Makefile, and a file pre-build in " "the scripts subdirectory, the <_:buildtarget-2/> target " "will be called after the regular extraction actions, and pre-" "build will be executed before the default build rules are done. " "It is recommended to use Makefile targets if the " "actions are simple enough, because it will be easier for someone to figure " "out what kind of non-default action the port requires." msgstr "" "Por exemplo, se houver um target <_:buildtarget-1/> definido no " "Makefile e um arquivo pre-build no " "subdiretório scripts, o target <_:buildtarget-2/> será " "chamado após as ações de extração regulares e pre-build " "será executado antes que as regras de compilação padrão sejam feitas. " "Recomenda-se usar targets no Makefile se as ações forem " "simples, porque será mais fácil para alguém descobrir que tipo de ação não " "padrão o port necessita." #. (itstool) path: para/buildtarget #: book.translate.xml:772 book.translate.xml:777 msgid "do-something" msgstr "dosomething" #. (itstool) path: para/buildtarget #: book.translate.xml:775 book.translate.xml:787 book.translate.xml:1233 -#: book.translate.xml:8584 book.translate.xml:19900 +#: book.translate.xml:8605 book.translate.xml:20423 msgid "do-extract" msgstr "do-extract" #. (itstool) path: sect1/para #: book.translate.xml:771 msgid "" "The default actions are done by the <_:buildtarget-1/> targets from " "bsd.port.mk. For example, the commands to extract a " "port are in the target <_:buildtarget-2/>. If the default target does not do " "the job right, redefine the <_:buildtarget-3/> target in the " "Makefile." msgstr "" "As ações padrão são feitas pelos targets <_:buildtarget-1/> do bsd." "port.mk. Por exemplo, os comandos para extrair um port estão no " "target <_:buildtarget-2/>. Se o target padrão não fizer o trabalho direito, " "redefina o target <_:buildtarget-3/> no Makefile." #. (itstool) path: para/buildtarget #: book.translate.xml:790 msgid "post-deinstall" msgstr "post-deinstall" #. (itstool) path: note/para #: book.translate.xml:781 msgid "" "The main targets (for example, <_:buildtarget-1/>, <_:" "buildtarget-2/>, etc.) do nothing more than make sure all the stages up to " "that one are completed and call the real targets or scripts, and they are " "not intended to be changed. To fix the extraction, fix <_:buildtarget-3/>, " "but never ever change the way <_:buildtarget-4/> operates! Additionally, the " "target <_:buildtarget-5/> is invalid and is not run by the ports " "infrastructure." msgstr "" "O target principal (por exemplo, <_:buildtarget-1/>, <_:" "buildtarget-2/>, etc.) fazem nada mais do que certificar-se de que todos os " "estágios até aquele estão concluídos e chamar os targets ou scripts reais, e " "eles não pretendem ser alterados. Para consertar a extração, corrija <_:" "buildtarget-3/>, mas nunca mude a forma como <_:buildtarget-4/> opera! Além " "disso, o target <_:buildtarget-5/> é inválido e não é executado pela " "infraestrutura de ports." #. (itstool) path: sect1/para #: book.translate.xml:794 msgid "" "Now that what goes on when the user types make install is " "better understood, let us go through the recommended steps to create the " "perfect port." msgstr "" "Agora que o que acontece quando o usuário digita make install é melhor entendido, vamos seguir as etapas recomendadas para criar " "o port perfeito." #. (itstool) path: sect1/title #: book.translate.xml:800 msgid "Getting the Original Sources" msgstr "Obtendo os Fontes Originais" #. (itstool) path: sect1/para #: book.translate.xml:802 msgid "" "Get the original sources (normally) as a compressed tarball (foo." "tar.gz or foo.tar.bz2) and copy it into DISTDIR. Always use " "mainstream sources when and where possible." msgstr "" "Obtenha os fontes originais (normalmente) como um tarball compactado " "(foo.tar.gz ou foo." "tar.bz2) e copie-o para DISTDIR. Use fontes do " "mainstream sempre que possível." #. (itstool) path: sect1/para #: book.translate.xml:809 msgid "" "Set the variable MASTER_SITES to reflect where the " "original tarball resides. Shorthand definitions exist for most mainstream " "sites in bsd.sites.mk. Please use these sites—and the " "associated definitions—if at all possible, to help avoid the problem of " "having the same information repeated over again many times in the source " "base. As these sites tend to change over time, this becomes a maintenance " "nightmare for everyone involved. See for details." msgstr "" "Definir a variável MASTER_SITES para refletir onde o " "tarball original reside. Existem definições abreviadas para a maioria dos " "sites mainstream em bsd.sites.mk. Por favor, use esses " "sites - e as definições associadas—se for possível, para ajudar a evitar o " "problema de ter as mesmas informações repetidas várias vezes na base de " "origem. Como esses sites tendem a mudar com o tempo, isso se torna um " "pesadelo de manutenção para todos os envolvidos. Veja para detalhes." #. (itstool) path: sect1/para #: book.translate.xml:820 msgid "" "If there is no FTP/HTTP site that is well-connected to the net, or can only " "find sites that have irritatingly non-standard formats, put a copy on a " "reliable FTP or HTTP server (for example, a home page)." msgstr "" "Se não houver nenhum site FTP/HTTP bem conectado à rede ou se puder " "encontrar apenas sites com formatos irritantemente não-padrão, coloque uma " "cópia em um servidor FTP ou HTTP confiável (por exemplo, uma home page)." #. (itstool) path: sect1/para #: book.translate.xml:826 msgid "" "If a convenient and reliable place to put the distfile cannot be found, we " "can house it ourselves on ftp.FreeBSD.org; however, this is the least-preferred solution. The distfile " "must be placed into ~/public_distfiles/ of someone's " "freefall account. Ask the person who commits the " "port to do this. This person will also set MASTER_SITES " "to LOCAL/username where " "username is their FreeBSD " "cluster login." msgstr "" "Se um lugar conveniente e confiável para colocar o distfile não puder ser " "encontrado, nós podemos hospedar em ftp.FreeBSD." "org; no entanto, esta é a solução menos preferida. O distfile " "deve ser colocado em ~/public_distfiles/ da conta " "freefall de alguém. Peça para a pessoa que for " "fazer o commit do port para realizer isso. Essa pessoa também irá definir " "MASTER_SITES para LOCAL/username onde username é o seu login do cluster do FreeBSD." #. (itstool) path: sect1/para #: book.translate.xml:838 msgid "" "If the port's distfile changes all the time without any kind of version " "update by the author, consider putting the distfile on a home page and " "listing it as the first MASTER_SITES. Try to talk the " "port author out of doing this; it really does help to establish some kind of " "source code control. Hosting a specific version will prevent users from " "getting checksum mismatch errors, and also reduce the " "workload of maintainers of our FTP site. Also, if there is only one master " "site for the port, it is recommended to house a backup on a home page and " "list it as the second MASTER_SITES." msgstr "" "Se o distfile do port mudar o tempo todo sem nenhum tipo de atualização de " "versão pelo autor, considere colocar o distfile em uma página pessoal e " "liste-a como o MASTER_SITES primário. Tente falar com o " "autor do port para parar de fazer isso; Isso realmente ajuda a estabelecer " "algum tipo de controle de código-fonte. Hospedar uma versão específica " "impedirá que os usuários obtenham erros de checksum mismatch, e também irá reduzir a carga de trabalho dos mantenedores do " "nosso site FTP. Além disso, se houver apenas um site master para o port, " "recomenda-se armazenar um backup em uma home page e listá-lo como o " "MASTER_SITES secundário." #. (itstool) path: sect1/para #: book.translate.xml:851 msgid "" "If the port requires additional patches that are available on the Internet, " "fetch them too and put them in DISTDIR. Do not worry if " "they come from a site other than where the main source tarball comes, we " "have a way to handle these situations (see the description of PATCHFILES below)." msgstr "" "Se o port exigir patches adicionais disponíveis na Internet, baixe-os também " "e coloque-os em DISTDIR. Não se preocupe se eles vierem " "de um site diferente de onde vem o tarball do código fonte principal, temos " "uma maneira de lidar com essas situações (veja a descrição PATCHFILES abaixo)." #. (itstool) path: sect1/title #: book.translate.xml:859 msgid "Modifying the Port" msgstr "Modificando o Port" #. (itstool) path: sect1/para #: book.translate.xml:861 msgid "" "Unpack a copy of the tarball in a private directory and make whatever " "changes are necessary to get the port to compile properly under the current " "version of FreeBSD. Keep careful track of steps, as " "they will be needed to automate the process shortly. Everything, including " "the deletion, addition, or modification of files has to be doable using an " "automated script or patch file when the port is finished." msgstr "" "Desempacote uma cópia do tarball em um diretório privado e faça as " "alterações necessárias para que o port compile corretamente sob a versão " "atual do FreeBSD. Atenção dobrada nessas etapas, pois " "elas serão necessárias para automatizar o processo em breve. Tudo, incluindo " "a exclusão, adição ou modificação de arquivos, devem ser realizados usando " "um script automatizado ou um arquivo patch quando o port estiver finalizado." #. (itstool) path: sect1/para #: book.translate.xml:870 msgid "" "If the port requires significant user interaction/customization to compile " "or install, take a look at one of Larry Wall's classic " "Configure scripts and perhaps do something " "similar. The goal of the new ports collection is to make each port as " "plug-and-play as possible for the end-user while using a " "minimum of disk space." msgstr "" "Se o port exigir interação/customização significativa do usuário para " "compilar ou instalar, dê uma olhada em um dos scripts " "Configure clássicos de Larry Wall e talvez faça " "algo semelhante. O objetivo da nova coleção de ports é fazer com que cada " "port seja plug-and-play o quanto possível para o usuário " "final, usando um mínimo de espaço em disco." #. (itstool) path: note/para #: book.translate.xml:880 msgid "" "Unless explicitly stated, patch files, scripts, and other files created and " "contributed to the FreeBSD ports collection are assumed to be covered by the " "standard BSD copyright conditions." msgstr "" "A menos que explicitamente declarado, os arquivos de patch, scripts e outros " "arquivos criados e contribuídos para a coleção de ports do FreeBSD são " "assumidos como cobertos pelas condições de copyright padrão do BSD." #. (itstool) path: sect1/title #: book.translate.xml:888 msgid "Patching" msgstr "Patching" #. (itstool) path: sect1/para #: book.translate.xml:890 msgid "" "In the preparation of the port, files that have been added or changed can be " "recorded with diff1 for later feeding to " "patch1. Doing this with a typical file involves saving a copy of the " "original file before making any changes using a .orig " "suffix." msgstr "" "Na preparação do port, arquivos que forem adicionados ou alterados podem ser " "gravados com diff1 para posterior inclusão em um " "patch1. Fazer isso com um arquivo típico envolve salvar uma cópia do " "arquivo original antes de fazer qualquer alteração usando um sufixo " ".orig." #. (itstool) path: sect1/screen #: book.translate.xml:896 #, no-wrap msgid "% cp file file.orig" msgstr "% cp file file.orig" #. (itstool) path: sect1/para #: book.translate.xml:898 msgid "" "After all changes have been made, cd back to the port " "directory. Use make makepatch to generate updated patch " "files in the files directory." msgstr "" "Depois que todas as alterações forem realizadas, cd de " "volta ao diretório do port. Execute make makepatch para " "gerar arquivos de patch atualizados no diretório files." #. (itstool) path: tip/para #: book.translate.xml:904 msgid "" "Use BINARY_ALIAS to substitute hardcoded commands during " "the build and avoid patching build files. See for more information." msgstr "" "Usar BINARY_ALIAS para substituir comandos codificados " "durante a compilação e para evitar patching de arquivos de compilação. Veja " " para maiores informações." #. (itstool) path: sect2/title #: book.translate.xml:911 msgid "General Rules for Patching" msgstr "Regras Gerais para Patching" #. (itstool) path: sect2/para #: book.translate.xml:913 msgid "" "Patch files are stored in PATCHDIR, usually " "files/, from where they will be automatically applied. " "All patches must be relative to WRKSRC. Typically " "WRKSRC is a subdirectory of WRKDIR, " "the directory where the distfile is extracted. Use make -V WRKSRC to see the actual path. The patch names are to follow these rules:" msgstr "" "Arquivos patch são armazenados em PATCHDIR, geralmente " "files/, de onde serão aplicados automaticamente. Todas " "os patches devem ser relativos ao WRKSRC. Tipicamente " "WRKSRC é um subdiretório de WRKDIR, o " "diretório onde o distfile é extraído. Execute make -V WRKSRC para ver o caminho real. Os nomes dos patches devem seguir estas " "regras:" #. (itstool) path: listitem/para #: book.translate.xml:925 msgid "" "Avoid having more than one patch modify the same file. For example, having " "both patch-foobar.c and patch-foobar.c2 making changes to ${WRKSRC}/foobar.c makes " "them fragile and difficult to debug." msgstr "" "Evite ter mais de um patch modificando o mesmo arquivo. Por exemplo, ter os " "dois patch-foobar.c e patch-foobar.c2 fazendo alterações em ${WRKSRC}/foobar.c " "torna-os frágeis e difíceis de serem depurados." #. (itstool) path: listitem/para #: book.translate.xml:934 msgid "" "When creating names for patch files, replace each underscore (_) with two underscores (__) and each slash " "(/) with one underscore (_). For " "example, to patch a file named src/freeglut_joystick.c, " "name the corresponding patch patch-src_freeglut__joystick.c. Do not name patches like patch-aa or " "patch-ab. Always use the path and file name in patch " "names. Using make makepatch automatically generates the " "correct names." msgstr "" "Ao criar nomes para arquivos de patch, substitua cada underline (_) com dois underlines (__) e cada barra " "(/) com um underline (_). Por exemplo, " "para corrigir um arquivo chamado src/freeglut_joystick.c nomeie o patch correspondente patch-" "src_freeglut__joystick.c. Não nomeie patches como patch-" "aa ou patch-ab. Sempre use o caminho e o " "nome do arquivo nos nomes dos patches. O make makepatch " "gera automaticamente os nomes corretos." #. (itstool) path: listitem/para #: book.translate.xml:950 msgid "" "A patch may modify multiple files if the changes are related and the patch " "is named appropriately. For example, patch-add-missing-stdlib.h." msgstr "" "Um patch pode modificar vários arquivos se as alterações estiverem " "relacionadas e o patch tiver o nome apropriado. Por exemplo, patch-" "add-missing-stdlib.h." #. (itstool) path: listitem/para #: book.translate.xml:957 msgid "" "Only use characters [-+._a-zA-Z0-9] for naming patches. " "In particular, do not use :: as a path " "separator, use _ instead." msgstr "" "Use apenas caracteres [-+._ a-zA-Z0-9] para nomear " "patches. Em particular, não use :: como um " "separador de path, use _ no lugar." #. (itstool) path: sect2/para #: book.translate.xml:965 msgid "" "Minimize the amount of non-functional whitespace changes in patches. It is " "common in the Open Source world for projects to share large amounts of a " "code base, but obey different style and indenting rules. When taking a " "working piece of functionality from one project to fix similar areas in " "another, please be careful: the resulting patch may be full of non-" "functional changes. It not only increases the size of the ports repository " "but makes it hard to find out what exactly caused the problem and what was " "changed at all." msgstr "" "Minimize a quantidade de mudanças de espaço em branco não funcionais em " "patches. É comum no mundo Open Source para projetos compartilhar grandes " "quantidades de uma base de código, mas obedecer a regras de recuo e estilo " "diferentes. Ao usar uma funcionalidade funcional de um projeto para " "consertar áreas similares em outra, por favor, tenha cuidado: o patch " "resultante pode estar cheio de mudanças não-funcionais. Ele não só aumenta o " "tamanho do repositório do ports, mas torna difícil descobrir o que " "exatamente causou o problema e o que foi alterado em todos." #. (itstool) path: sect2/para #: book.translate.xml:975 msgid "" "If a file must be deleted, do it in the <_:buildtarget-1/> target rather " "than as part of the patch." msgstr "" "Se um arquivo precisar ser excluído, faça-o no target <_:buildtarget-1/> em " "vez de como parte do patch." #. (itstool) path: sect2/title #: book.translate.xml:982 msgid "Manual Patch Generation" msgstr "Geração Manual de Patches" #. (itstool) path: note/para #: book.translate.xml:985 msgid "" "Manual patch creation is usually not necessary. Automatic patch generation " "as described earlier in this section is the preferred method. However, " "manual patching may be required occasionally." msgstr "" "A criação manual de patches geralmente não é necessária. A geração " "automática de patches, conforme descrito anteriormente nesta seção, é o " "método preferido. No entanto, patches manuais podem ser necessários " "ocasionalmente." #. (itstool) path: sect2/para #: book.translate.xml:991 msgid "" "Patches are saved into files named patch-* where " "* indicates the pathname of the file that is " "patched, such as patch-Imakefile or patch-src-" "config.h." msgstr "" "Patches são salvos em arquivos nomeados como patch-* " "onde * indica o nome do caminho do arquivo que " "está sendo feito o patch, como patch-imakefile ou " "patch-src-config.h." #. (itstool) path: sect2/para #: book.translate.xml:998 msgid "" "After the file has been modified, diff1 is used to record the " "differences between the original and the modified version. " "faz com que o diff1 produza diffs unificados, a forma " "preferida." #. (itstool) path: sect2/screen #: book.translate.xml:1003 #, no-wrap msgid "% diff -u file.orig file > patch-pathname-file" msgstr "% diff -u file.orig file > patch-pathname-file" #. (itstool) path: sect2/para #: book.translate.xml:1005 msgid "" "When generating patches for new, added files, is used to " "tell diff1 to treat the non-existent original file as if it " "existed but was empty:" msgstr "" "Ao gerar patches para novos arquivos adicionados, é " "usado para dizer ao diff1 para tratar o arquivo " "original inexistente como se existisse, mas estava vazio:" #. (itstool) path: sect2/screen #: book.translate.xml:1010 #, no-wrap msgid "% diff -u -N newfile.orig newfile > patch-pathname-newfile" msgstr "% diff -u -N newfile.orig newfile > patch-pathname-newfile" #. (itstool) path: sect2/para #: book.translate.xml:1012 msgid "" "Do not add $FreeBSD$ RCS strings in patches. When patches " "are added to the Subversion repository with " "svn add, the fbsd:nokeywords property " "is set to yes automatically so keywords in the patch are " "not modified when committed. The property can be added manually with " "svn propset fbsd:nokeywords yes files...." msgstr "" "Não adicione Strings RCS $FreeBSD$ em patches. Quando os " "patches são adicionados ao repositório Subversion " "com svn add, a propriedade fbsd:nokeywords é definida para yes automaticamente para que as " "keywords no patch não sejam modificadas no commit. A propriedade pode ser " "adicionada manualmente svn propset fbsd:nokeywords yes " "files...." #. (itstool) path: sect2/para #: book.translate.xml:1022 msgid "" "Using the recurse () option to " "diff1 to generate patches is fine, but please look at the resulting " "patches to make sure there is no unnecessary junk in there. In particular, " "diffs between two backup files, Makefiles when the port " "uses Imake or GNU configure, etc., are " "unnecessary and have to be deleted. If it was necessary to edit " "configure.in and run autoconf to " "regenerate configure, do not take the diffs of " "configure (it often grows to a few thousand lines!). " "Instead, define USES=autoreconf and take the diffs of " "configure.in." msgstr "" "Usar a opção () do diff1 para gerar patches é " "razoável, mas por favor, analise os patches resultantes para se certificar " "de que não há nenhum lixo desnecessário neles. Em particular, diffs entre " "dois arquivos de backup, quando o port usa Imake ou GNU " "configure, etc., diffs de Makefiles " "são desnecessários e devem ser eliminados. Se for necessário editar o " "configure.in e executar o autoconf " "para regerar o configure, não gere diffs do " "configure (ele geralmente cresce para algumas milhares de " "linhas!). Em vez disso, defina USES=autoreconf e gere os " "diffs no configure.in." #. (itstool) path: sect2/title #: book.translate.xml:1040 msgid "Simple Automatic Replacements" msgstr "Substituições Automáticas Simples" #. (itstool) path: sect2/para #: book.translate.xml:1042 msgid "" "Simple replacements can be performed directly from the port " "Makefile using the in-place mode of " "sed1. This is useful when changes use the value of a variable:" msgstr "" "Substituições simples podem ser realizadas diretamente do " "Makefile do port usando o modo in-loco do " "sed1. Isso é útil quando as alterações usam o valor de uma variável:" #. (itstool) path: sect2/programlisting #: book.translate.xml:1047 #, no-wrap msgid "" "post-patch:\n" "\t@${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README" msgstr "" "post-patch:\n" "\t@${REINPLACE_CMD} -e 's|for Linux|for FreeBSD|g' ${WRKSRC}/README" #. (itstool) path: sect2/para #: book.translate.xml:1050 msgid "" "Quite often, software being ported uses the CR/LF convention in source " "files. This may cause problems with further patching, compiler warnings, or " "script execution (like /bin/sh^M not found.) To quickly " "convert all files from CR/LF to just LF, add this entry to the port " "Makefile:" msgstr "" "Muitas vezes, o software sendo portado usa a convenção CR/LF nos arquivos " "fonte. Isso pode causar problemas com correções adicionais, avisos do " "compilador ou execução de scripts (como /bin/sh^M não encontrado.) Para converter rapidamente todos os arquivos de CR/LF para apenas " "LF, adicione essa entrada ao Makefile do port:" #. (itstool) path: sect2/programlisting #: book.translate.xml:1057 #, no-wrap msgid "USES=\tdos2unix" msgstr "USES=\tdos2unix" #. (itstool) path: sect2/para #: book.translate.xml:1059 msgid "A list of specific files to convert can be given:" msgstr "Uma lista de arquivos específicos para conversão pode ser informada:" #. (itstool) path: sect2/programlisting #: book.translate.xml:1061 #, no-wrap msgid "" "USES=\tdos2unix\n" "DOS2UNIX_FILES=\tutil.c util.h" msgstr "" "USES=\tdos2unix\n" "DOS2UNIX_FILES=\tutil.c util.h" #. (itstool) path: sect2/para #: book.translate.xml:1064 msgid "" "Use DOS2UNIX_REGEX to convert a group of files across " "subdirectories. Its argument is a find1-compatible regular " "expression. More on the format is in re_format7. This option is useful " "for converting all files of a given extension. For example, convert all " "source code files, leaving binary files intact:" msgstr "" "Use DOS2UNIX_REGEX para converter um grupo de arquivos em " "subdiretórios. Seu argumento é um find1 compatível com " "expressão regular. Mais sobre o formato está em " "re_format7. Esta opção é útil para converter todos os " "arquivos de uma determinada extensão. Por exemplo, converta todos os " "arquivos de código-fonte, deixando os arquivos binários intactos:" #. (itstool) path: sect2/programlisting #: book.translate.xml:1072 #, no-wrap msgid "" "USES=\tdos2unix\n" "DOS2UNIX_REGEX=\t.*\\.([ch]|cpp)" msgstr "" "USES=\tdos2unix\n" "DOS2UNIX_REGEX=\t.*\\.([ch]|cpp)" #. (itstool) path: sect2/para #: book.translate.xml:1075 msgid "" "A similar option is DOS2UNIX_GLOB, which runs " "find for each element listed in it." msgstr "" "Uma opção similar é DOS2UNIX_GLOB, que executa o " "find para cada elemento listado nele." #. (itstool) path: sect2/programlisting #: book.translate.xml:1079 #, no-wrap msgid "" "USES=\tdos2unix\n" "DOS2UNIX_GLOB=\t*.c *.cpp *.h" msgstr "" "USES=\tdos2unix\n" "DOS2UNIX_GLOB=\t*.c *.cpp *.h" #. (itstool) path: sect2/para #: book.translate.xml:1083 msgid "" "The base directory for the conversion can be set. This is useful when there " "are multiple distfiles and several contain files which require line-ending " "conversion." msgstr "" "O diretório base para a conversão pode ser definido. Isso é útil quando há " "vários distfiles e vários arquivos contidos que requerem conversão de fim de " "linha." #. (itstool) path: sect2/programlisting #: book.translate.xml:1087 #, no-wrap msgid "" "USES=\tdos2unix\n" "DOS2UNIX_WRKSRC=\t${WRKDIR}" msgstr "" "USES=\tdos2unix\n" "DOS2UNIX_WRKSRC=\t${WRKDIR}" #. (itstool) path: sect2/title #: book.translate.xml:1092 msgid "Patching Conditionally" msgstr "Corrigindo Condicionalmente" #. (itstool) path: sect2/para #: book.translate.xml:1094 msgid "" "Some ports need patches that are only applied for specific FreeBSD versions " "or when a particular option is enabled or disabled. Conditional patches are " "specified by placing the full paths to the patch files in " "EXTRA_PATCHES." msgstr "" "Alguns ports precisam de patches que são aplicados apenas para versões " "específicas do FreeBSD ou quando uma determinada opção é ativada ou " "desativada. Os patches condicionais são especificados colocando-se os " "caminhos completos para os arquivos de patch emEXTRA_PATCHES." #. (itstool) path: example/title #: book.translate.xml:1101 msgid "Applying a Patch for a Specific FreeBSD Version" msgstr "Aplicando um Patch para uma Versão Específica do FreeBSD" #. (itstool) path: example/programlisting #: book.translate.xml:1103 #, no-wrap msgid "" ".include <bsd.port.options.mk>\n" "\n" "# Patch in the iconv const qualifier before this\n" ".if ${OPSYS} == FreeBSD && ${OSVERSION} < 1100069\n" "EXTRA_PATCHES=\t${PATCHDIR}/extra-patch-fbsd10\n" ".endif\n" "\n" ".include <bsd.port.mk>" msgstr "" ".include <bsd.port.options.mk>\n" "\n" "# Patch in the iconv const qualifier before this\n" ".if ${OPSYS} == FreeBSD && ${OSVERSION} < 1100069\n" "EXTRA_PATCHES=\t${PATCHDIR}/extra-patch-fbsd10\n" ".endif\n" "\n" ".include <bsd.port.mk>" #. (itstool) path: example/title #: book.translate.xml:1114 msgid "Optionaly Applying a Patch" msgstr "Aplicando Opcionalmente um Patch" #. (itstool) path: example/para #: book.translate.xml:1116 msgid "" "When an option requires a patch, " "use opt_EXTRA_PATCHES and " "opt_EXTRA_PATCHES_OFF to make " "the patch conditional on the opt option. See for more " "information." msgstr "" "Quando um option requer um patch, " "useopt_EXTRA_PATCHES e " "opt_EXTRA_PATCHES_OFF para " "fazer o patch condicional na opção opt. Veja Para maiores " "informações." #. (itstool) path: example/programlisting #: book.translate.xml:1126 #, no-wrap msgid "" "OPTIONS_DEFINE=\t FOO BAR\n" "FOO_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-foo\n" "BAR_EXTRA_PATCHES_OFF=\t${PATCHDIR}/extra-patch-bar.c \\\n" "\t\t${PATCHDIR}/extra-patch-bar.h" msgstr "" "OPTIONS_DEFINE=\t FOO BAR\n" "FOO_EXTRA_PATCHES= ${PATCHDIR}/extra-patch-foo\n" "BAR_EXTRA_PATCHES_OFF=\t${PATCHDIR}/extra-patch-bar.c \\\n" "\t\t${PATCHDIR}/extra-patch-bar.h" #. (itstool) path: example/title #: book.translate.xml:1133 msgid "Using EXTRA_PATCHES With a Directory" msgstr "Usando EXTRA_PATCHES Com um Diretório" #. (itstool) path: example/para #: book.translate.xml:1136 msgid "" "Sometime, there are many patches that are needed for a feature, in this " "case, it is possible to point EXTRA_PATCHES to a " "directory, and it will automatically apply all files named patch-" "* in it." msgstr "" "As vezes, existem muitos patches que são necessários para um recurso, neste " "caso, é possível apontar EXTRA_PATCHES para um diretório, " "e ele aplicará automaticamente todos os arquivos nomeados como " "patch* nele." #. (itstool) path: example/para #: book.translate.xml:1143 msgid "" "Create a subdirectory in ${PATCHDIR}, and move the " "patches in it. For example:" msgstr "" "Crie um subdiretório em ${PATCHDIR}, e mova os patches " "para ele. Por exemplo:" #. (itstool) path: example/screen #: book.translate.xml:1147 #, no-wrap msgid "" "% ls -l files/foo-patches\n" "-rw-r--r-- 1 root wheel 350 Jan 16 01:27 patch-Makefile.in\n" "-rw-r--r-- 1 root wheel 3084 Jan 18 15:37 patch-configure" msgstr "" "% ls -l files/foo-patches\n" "-rw-r--r-- 1 root wheel 350 Jan 16 01:27 patch-Makefile.in\n" "-rw-r--r-- 1 root wheel 3084 Jan 18 15:37 patch-configure" #. (itstool) path: example/para #: book.translate.xml:1151 msgid "Then add this to the Makefile:" msgstr "Então adicione isso ao Makefile:" #. (itstool) path: example/programlisting #: book.translate.xml:1153 #, no-wrap msgid "" "OPTIONS_DEFINE=\tFOO\n" "FOO_EXTRA_PATCHES=\t${PATCHDIR}/foo-patches" msgstr "" "OPTIONS_DEFINE=\tFOO\n" "FOO_EXTRA_PATCHES=\t${PATCHDIR}/foo-patches" #. (itstool) path: example/para #: book.translate.xml:1156 msgid "" "The framework will then use all the files named patch-" "* in that directory." msgstr "" "O framework irá então usar todos os arquivos nomeados " "patch* nesse diretório." #. (itstool) path: sect1/title #: book.translate.xml:1164 msgid "Configuring" msgstr "Configurando" #. (itstool) path: sect1/para #: book.translate.xml:1166 msgid "" "Include any additional customization commands in the configure script and save it in the scripts " "subdirectory. As mentioned above, it is also possible do this with " "Makefile targets and/or scripts with the name " "pre-configure or post-configure." msgstr "" "Inclua quaisquer comandos de personalização adicionais no script " "configure e salve-o no subdiretório scripts. Como mencionado acima, também é possível fazer isso com targets " "no Makefile e/ou scripts com o nome pre-" "configure ou post-configure." #. (itstool) path: sect1/title #: book.translate.xml:1176 msgid "Handling User Input" msgstr "Manipulando a Entrada do Usuário" #. (itstool) path: sect1/para #: book.translate.xml:1178 msgid "" "If the port requires user input to build, configure, or install, set " "IS_INTERACTIVE in the Makefile. This " "will allow overnight builds to skip it. If the user sets the " "variable BATCH in their environment (and if the user sets the " "variable INTERACTIVE, then only those " "ports requiring interaction are built). This will save a lot of wasted time " "on the set of machines that continually build ports (see below)." msgstr "" "Se o port requer intervenção do usuário para build, configure ou install, " "defina IS_INTERACTIVE no Makefile. " "Isso fará com que os overnight builds pulem ele. Se o usuário " "definir a variável BATCH em seu ambiente (e se o usuário " "definir a variável INTERATIVE, então apenas aqueles ports que requerem interação serão compilados). Isso " "economizará muito tempo perdido no conjunto de máquinas que continuamente " "compilam ports (veja abaixo)." #. (itstool) path: sect1/para #: book.translate.xml:1188 msgid "" "It is also recommended that if there are reasonable default answers to the " "questions, PACKAGE_BUILDING be used to turn off the " "interactive script when it is set. This will allow us to build the packages " "for CDROMs and FTP." msgstr "" "Também é recomendado que, se houver respostas padrão razoáveis ​​para as " "perguntas, PACKAGE_BUILDING pode usado para desativar a " "intervenção do usuário quando o mesmo estiver definido. Isso nos permitirá " "compilar os pacotes para CDROMs e FTP." #. (itstool) path: chapter/title #: book.translate.xml:1204 msgid "Configuring the Makefile" msgstr "Configurando o Makefile" #. (itstool) path: chapter/para #: book.translate.xml:1206 msgid "" "Configuring the Makefile is pretty simple, and again we " "suggest looking at existing examples before starting. Also, there is a sample Makefile in this handbook, so take " "a look and please follow the ordering of variables and sections in that " "template to make the port easier for others to read." msgstr "" "Configurar o Makefile é bastante simples e, novamente, " "sugerimos examinar os exemplos existentes antes de começar. Além disso, há " "um Makefile de exemplo neste " "manual, então dê uma olhada e por favor siga a ordem das variáveis ​​e seções " "naquele modelo para tornar o port mais fácil para os outros lerem." #. (itstool) path: chapter/para #: book.translate.xml:1214 msgid "" "Consider these problems in sequence during the design of the new " "Makefile:" msgstr "" "Considere estes problemas em sequência durante o projeto do novo " "Makefile:" #. (itstool) path: sect1/title #: book.translate.xml:1218 msgid "The Original Source" msgstr "O Código Fonte Original" #. (itstool) path: sect1/para #: book.translate.xml:1220 msgid "" "Does it live in DISTDIR as a standard gzipped tarball named something like foozolix-1.2.tar.gz? If so, go on to the next step. If not, the distribution file " "format might require overriding one or more of DISTVERSION, DISTNAME, EXTRACT_CMD, " "EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX, or DISTFILES." msgstr "" "Ele está em DISTDIR como um tarball gzip e é chamado de algo como foozolix-1.2.tar.gz? " "Se assim for, vá para o próximo passo. Caso contrário, o formato do arquivo " "de distribuição pode necessitar da substituição de uma ou mais das variáveis " "DISTVERSION, DISTNAME, " "EXTRACT_CMD, EXTRACT_BEFORE_ARGS, " "EXTRACT_AFTER_ARGS, EXTRACT_SUFX ou " "DISTFILES." #. (itstool) path: sect1/para #: book.translate.xml:1232 msgid "" "In the worst case, create a custom <_:buildtarget-1/> target to override the " "default. This is rarely, if ever, necessary." msgstr "" "Na pior das hipóteses, crie um target personalizado <_:buildtarget-1/> para " "substituir o padrão. Isso raramente é necessário." #. (itstool) path: sect1/title #: book.translate.xml:1238 msgid "Naming" msgstr "Nomeando" #. (itstool) path: sect1/para #: book.translate.xml:1240 msgid "" "The first part of the port's Makefile names the port, " "describes its version number, and lists it in the correct category." msgstr "" "A primeira parte do Makefile do port o nomeia, descreve " "seu número de versão e o lista na categoria correta." #. (itstool) path: sect2/title #. (itstool) path: row/entry #: book.translate.xml:1245 book.translate.xml:1971 msgid "PORTNAME" msgstr "PORTNAME" #. (itstool) path: sect2/para #: book.translate.xml:1247 msgid "" "Set PORTNAME to the base name of the software. It is used " "as the base for the FreeBSD package, and for DISTNAME." msgstr "" "Setar PORTNAME ao nome base do software. Isso é usado " "como base para o pacote do FreeBSD, e para o DISTNAME." #. (itstool) path: important/para #: book.translate.xml:1252 msgid "" "The package name must be unique across the entire ports tree. Make sure that " "the PORTNAME is not already in use by an existing port, " "and that no other port already has the same PKGBASE. If " "the name has already been used, add either PKGNAMEPREFIX or " "PKGNAMESUFFIX." msgstr "" "O nome do pacote deve ser único em toda a árvore de ports. Certifique-se de " "que o PORTNAME já não está em uso por um port existente, " "e que nenhum outro port já tem o mesmo PKGBASE. Se o nome " "já tiver sido usado, adicione PKGNAMEPREFIX ou PKGNAMESUFFIX." #. (itstool) path: sect2/title #: book.translate.xml:1262 msgid "" "Versions, DISTVERSION or " "PORTVERSION" msgstr "" "Versões, DISTVERSION ou PORTVERSION" #. (itstool) path: sect2/para #: book.translate.xml:1265 msgid "" "Set DISTVERSION to the version number of the software." msgstr "" "Setar DISTVERSION para o número da versão do software." #. (itstool) path: sect2/para #: book.translate.xml:1268 msgid "" "PORTVERSION is the version used for the FreeBSD package. " "It will be automatically derived from DISTVERSION to be " "compatible with FreeBSD's package versioning scheme. If the version contains " "letters, it might be needed to set " "PORTVERSION and not DISTVERSION." msgstr "" "PORTVERSION é a versão usada para o pacote do FreeBSD. " "Será automaticamente derivado de DISTVERSION para ser " "compatível com o esquema de versionamento de pacotes do FreeBSD. Se a versão " "contiver letras, pode ser necessário definir " "PORTVERSIONe não DISTVERSION." #. (itstool) path: important/para #: book.translate.xml:1277 msgid "" "Only one of PORTVERSION and DISTVERSION can be set at a time." msgstr "" "Não é possível utilizar PORTVERSION e " "DISTVERSION juntos, deve ser ser definido um de cada vez." #. (itstool) path: sect2/para #: book.translate.xml:1281 msgid "" "From time to time, some software will use a version scheme that is not " "compatible with how DISTVERSION translates in " "PORTVERSION." msgstr "" "De tempos em tempos, alguns softwares usam um esquema de versão que não é " "compatível em como o DISTVERSION traduz a versão no " "PORTVERSION." #. (itstool) path: tip/para #: book.translate.xml:1287 msgid "" "When updating a port, it is possible to use pkg-" "version8's