From owner-svn-doc-all@freebsd.org Sun Oct 21 23:53:45 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 206D91039D15; Sun, 21 Oct 2018 23:53:45 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFD4B7D6A6; Sun, 21 Oct 2018 23:53:44 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B72131497F; Sun, 21 Oct 2018 23:53:44 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w9LNri3d062025; Sun, 21 Oct 2018 23:53:44 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w9LNriEW062019; Sun, 21 Oct 2018 23:53:44 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201810212353.w9LNriEW062019@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Sun, 21 Oct 2018 23:53:44 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52397 - in head/pt_BR.ISO8859-1/books: . porters-handbook X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/books: . porters-handbook X-SVN-Commit-Revision: 52397 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2018 23:53:45 -0000 Author: ebrandi Date: Sun Oct 21 23:53:43 2018 New Revision: 52397 URL: https://svnweb.freebsd.org/changeset/doc/52397 Log: pt_BR.ISO8859-1/books/porters-handbook: New pt_BR translation into .po format - content synchronized with en_US document (rev 52124) - book.xml converted to .po - .po file was translated to pt_BR - .po and .xml file has been set to UTF-8 encoding - information about volunteers who translated and/or revised the document was added to the header of the .po file. Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/books/porters-handbook/ head/pt_BR.ISO8859-1/books/porters-handbook/Makefile (contents, props changed) head/pt_BR.ISO8859-1/books/porters-handbook/book.xml (contents, props changed) head/pt_BR.ISO8859-1/books/porters-handbook/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/books/Makefile Modified: head/pt_BR.ISO8859-1/books/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/books/Makefile Sun Oct 21 16:01:09 2018 (r52396) +++ head/pt_BR.ISO8859-1/books/Makefile Sun Oct 21 23:53:43 2018 (r52397) @@ -8,6 +8,7 @@ SUBDIR+= dev-model SUBDIR+= faq SUBDIR+= fdp-primer +SUBDIR+= porters-handbook DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/books/porters-handbook/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/books/porters-handbook/Makefile Sun Oct 21 23:53:43 2018 (r52397) @@ -0,0 +1,50 @@ +# +# $FreeBSD$ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# Build the FreeBSD Porter's Handbook. +# + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= book + +FORMATS?= html-split + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +# XML content +SRCS= book.xml + +# Images from the cross-document image library +IMAGES_LIB+= callouts/1.png +IMAGES_LIB+= callouts/2.png +IMAGES_LIB+= callouts/3.png +IMAGES_LIB+= callouts/4.png +IMAGES_LIB+= callouts/5.png +IMAGES_LIB+= callouts/6.png +IMAGES_LIB+= callouts/7.png +IMAGES_LIB+= callouts/8.png +IMAGES_LIB+= callouts/9.png +IMAGES_LIB+= callouts/10.png +IMAGES_LIB+= callouts/11.png +IMAGES_LIB+= callouts/12.png +IMAGES_LIB+= callouts/13.png +IMAGES_LIB+= callouts/14.png +IMAGES_LIB+= callouts/15.png +IMAGES_LIB+= callouts/16.png +IMAGES_LIB+= callouts/17.png +IMAGES_LIB+= callouts/18.png +IMAGES_LIB+= callouts/19.png +IMAGES_LIB+= callouts/20.png +IMAGES_LIB+= callouts/21.png + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +SYMLINKS= ${DESTDIR} index.html handbook.html + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/books/porters-handbook/book.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/books/porters-handbook/book.xml Sun Oct 21 23:53:43 2018 (r52397) @@ -0,0 +1,23177 @@ + + + + + + + + + + + + + + + + + + + + +]> + + + + FreeBSD Porter's Handbook + + + Projeto de Documentação do FreeBSD + + + $FreeBSD$ + + 2000200120022003200420052006200720082009201020112012201320142015201620172018Projeto 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$ + + + + + + + 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 check-orphans + + + + 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. + + *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***