Rffontenelle (talk | contribs) m (adding -> Adding (start sentence with uppercase A)) |
Rffontenelle (talk | contribs) (→branch e estado atual no promtp de shell: Translation) |
||
(9 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
{{autolang}} | {{autolang}} | ||
Esta página fornece algumas instruções básicas para o uso diário do sistema de manutenção de pacotes baseado em [http://git-scm.com/ git] para o Fedora. Destina-se principalmente a mantenedores de pacotes Fedora novos e atuais, mas [[#anon|cobre brevemente o uso anônimo somente leitura do sistema]]. Não é um guia para o pacote RPM em si. Algum conhecimento pré-existente sobre git pode ser útil, mas não é um pré-requisito (na verdade, o pacote do Fedora pode ser uma introdução relativamente fácil). | |||
Você pode estar procurando ou também estar interessado em: | |||
* [[How_to_create_an_RPM_package| | * [[How_to_create_an_RPM_package|Aprendendo a criar pacotes]] | ||
* [[Join_the_package_collection_maintainers| | * [[Join_the_package_collection_maintainers/pt-br|Se tornando um mantenedor de pacote]] | ||
* [[Package_update_HOWTO| | * [[Package_update_HOWTO|Enviando atualizações de pacote]] | ||
* [[New_package_process_for_existing_contributors| | * [[New_package_process_for_existing_contributors|Adicionando um novo pacote ao repositório]] como um mantenedor existente | ||
* [[PackageDB_admin_requests#Additional_branches_for_existing_packages| | * [[PackageDB_admin_requests#Additional_branches_for_existing_packages|Adicionando um novo brancho de lançamento]] a um pacote existente | ||
* [[Packaging:Guidelines| | * [[Packaging:Guidelines|As diretrizes de empacotamento]] | ||
== | == Instalando ''fedpkg'' e fazendo a configuração inicial == | ||
Comece instalando {{package|fedpkg}} com {{command|dnf install fedpkg}}. Esta será sua interface principal para o sistema de empacotamento. | |||
Você também deve ter uma chave ssh configurada no [https://admin.fedoraproject.org/accounts/ Fedora Accounts System] para poder fazer alterações em qualquer pacote (incluindo os seus). O fedpkg espera que a chave ssh correta esteja disponível em seu chaveiro. | |||
Antes de fazer o upload dos fontes com <code>new-sources</code> e <code>upload</code> e compilar pacotes no Koji (com <code>build</code> por exemplo), você tem primeiro que obter suas credenciais Kerberos com <code>kinit</code>. Por exemplo: | |||
kinit [ | kinit [nome_de_usuário_FAS]@FEDORAPROJECT.ORG | ||
( | (Mantenha FEDORAPROJECT.ORG em caixa alta) | ||
Defina seu nome de usuário do Fedora Account System em {{filename|~/.fedora.upn}}. Você pode fazer isso por meio de {{command|echo "nome_de_usuário_FAS" > ~/.fedora.upn}}. | |||
== | == Comandos comuns do fedpkg == | ||
Esta seção lista os comandos típicos do fedpkg em um fluxo de trabalho normal, com breves descrições. Neste fluxo de trabalho, estaremos operando no branch do [[Releases/Rawhide|Rawhide]] do pacote. | |||
* | * Faça o checkout de um pacote: | ||
fedpkg co < | fedpkg co <nome_pacote_fontes> | ||
cd < | cd <nome_pacote_fontes> | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso obtém uma cópia os fontes do pacote do servidor. É conhecido como sua "cópia de trabalho".|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Atualize sua cópia em local do servidor Fedora: | ||
fedpkg pull | fedpkg pull | ||
* | * Obtenha os fontes do pacote: | ||
fedpkg sources | fedpkg sources | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso faz um pull de todas as fontes armazenadas no "cache lookaside" (veja mais abaixo). Passos como {{command|fedpkg prep}} e {{command|fedpkg srpm}} farão isso se necessário, mas você pode querer uma cópia imediatamente.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Faça suas alterações no pacote | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Este não é um guia de empacotamento RPM, portanto, presumiremos que você sabe o que está fazendo aqui. Novas fontes e patches vão para o diretório da cópia de trabalho por enquanto.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Execute o estágio "prep" (extrai fontes, aplica patches etc) dentro do diretório de checkout: | ||
fedpkg prep | fedpkg prep | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso é útil para garantir que seus patches sejam aplicados de forma limpa e para inspecionar a árvore de fontes, se necessário.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Faça uma compilação local do estado atual: | ||
fedpkg local | fedpkg local | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Este é o tipo mais simples de compilação de teste, mas geralmente é mais limpo e um teste melhor para fazer uma compilação scratch Mock ou Koji (veja abaixo).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Faça uma compilação com mock do estado atual: | ||
fedpkg mockbuild | fedpkg mockbuild | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso aciona uma compilação do [https://github.com/rpm-software-management/mock/wiki Mock], se você tiver o Mock configurado corretamente. [[Using_Mock_to_test_package_builds]] pode ajudar nisso.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* Generate a .src.rpm from the current state: | * Generate a .src.rpm from the current state: | ||
fedpkg srpm | fedpkg srpm | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Você pode solicitar uma "scratch build" ao [[Koji]] (uma compilação de teste, que não irá para nenhum repositório) do .src.rpm gerado com o comando {{command|koji build --scratch}} (consulte {{command|man koji}}).|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Faça uma compilação scratch usando koji: veja sobre [https://fedoraproject.org/wiki/Using_the_Koji_build_system#Scratch_Builds compilações scratch com Koji] | ||
* | * Verifique a alterações que você fez: | ||
fedpkg diff | fedpkg diff | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso é útil para garantir que você não tocou em algo por engano, se esqueceu de alterar o lançamento ou se esqueceu de incluir um changelog...|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Execute algumas verificações (rpmlint) em seu pacote: | ||
fedpkg lint | fedpkg lint | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Se você quiser colocar alguns erros rpmlint na lista de permissões e evitar que eles apareçam, você pode criar um arquivo de configuração rpmlint chamado <code><nome_pacote_fontes>.rpmlintrc</code> e será aplicado.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Mova para stage quaisquer patches ou novos arquivos fontes para fazer commit: | ||
git add ( | git add (algum_arquivo) | ||
{{hidden|header= | {{hidden|header=Detalhes|content=O git não considera todos os arquivos no diretório de trabalho como parte do repositório git por padrão (útil, para manter outros arquivos relevantes, como a árvore de fontes). Isso diz ao git para começar a considerar esses arquivos como parte do repositório ''localmente''. Quando você faz "commit" e "push" depois, essa mudança é comunicada ao servidor.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Envie os novos arquivos fontes para o cache lookaside: | ||
fedpkg new-sources | fedpkg new-sources | ||
{{admon/warning| | {{admon/warning|Alerta|Isso substituirá a lista atual de arquivos fontes, e não adicionará a ela. Consulte ''Detalhes'' para obter mais detalhes sobre o sistema de cache lookaside.}} | ||
fedpkg upload | fedpkg upload | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Fontes upstream "intocadas" (como tarballs de lançamento) e outros arquivos fonte maiores são armazenados no sistema de [[Package_Source_Control#Lookaside_Cache|cache lookaside]], não comprometidos diretamente com o git. Isso fornece armazenamento e transferência de arquivos mais eficientes. Os arquivos {{filename|sources}} e {{filename|.gitignore}} no repositório o mantém em sincronia com o cache lookaside. Toda vez que você usar {{command|fedpkg new-sources}} ou {{command|fedpkg upload}}, você deve se lembrar de fazer "commit" das alterações nesses arquivos. | ||
{{command|new-sources}} | {{command|new-sources}} "começa do zero", substituindo todos os arquivos atualmente no cache lookaside - você normalmente usará este comando para muitos pacotes com apenas um único tarball de fontes, cada vez que você atualizar para uma nova versão upstream. {{command|upload}} apenas adiciona o arquivo fornecido aos que já estão no cache. Lembre-se de não deixar fontes obsoletas por aí.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Troque para um branch diferente de lançamento: | ||
fedpkg switch-branch <f{{FedoraVersionNumber}}, el6, rawhide> | fedpkg switch-branch <f{{FedoraVersionNumber}}, el6, rawhide> | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Cada versão do Fedora tem seu próprio branch em cada repositório de pacotes, de forma que diferentes compilações podem ser enviadas para cada versão. Veja abaixo mais detalhes sobre como trabalhar com branches.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Gere o changelog do git do changelog do pacote: | ||
fedpkg clog | fedpkg clog | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Este comando extrai a entrada do changelog do pacote para o arquivo {{filename|clog}}, então você pode usá-lo como o changelog git se quiser. Alguns mantenedores fazem uma distinção entre os dois, outros não.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Faça commit das alterações: | ||
fedpkg commit (-F clog) (-p) (-c) | fedpkg commit (-F clog) (-p) (-c) | ||
{{admon/note| | {{admon/note|Diferença do git|Isso se comporta por padrão como {{command|git commit -a}} - ele organiza arquivos modificados e confirma todos de uma vez, embora ''não'' adicione arquivos que o git ainda não esteja rastreando.}} | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso cria uma espécie de pacote, um "commit", de suas mudanças no repositório, com uma identidade única e um changelog. Outros mantenedores - e você, mais tarde - podem ver o histórico de mudanças no repositório com o "commit" como o melhor nível de detalhe. É uma boa prática usar muitos commits relativamente pequenos, cada um para um único propósito - não combine um aumento de versão com um monte de correções de espaço em branco e algumas mudanças de scriptlet tudo em um commit, crie commits separados para cada um. | ||
O parâmetro {{command|-F clog}} usará o arquivo {{filename|clog}} da etapa anterior como o changelog. {{command|-p}} irá empurrar (veja abaixo) ao mesmo tempo que comete. {{command|-c}} combina os passos {{command|clog}} e {{command|commit -F clog}} em um, se você quiser.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | |||
* | * Faça push das alterações: | ||
fedpkg push | fedpkg push | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso envia todos os novos "commits" em sua cópia de trabalho local para o servidor upstream. Se você ainda está aprendendo o sistema, agora é um bom momento para {{command|fedpkg co}} outra cópia do repositório em outro lugar, compare o que você obteve com sua cópia de trabalho e execute um teste de compilação nela.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Faça uma compilação "oficial" das alterações nos últimos "pushes": | ||
fedpkg build | fedpkg build | ||
* | * Envia compilações "oficiais" de um branch | ||
fedpkg build | fedpkg build | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Não há diferença na linha de comando para enviar várias compilações de um fluxo de branch. Mas você precisa criar um arquivo de configuração {{command|package.cfg}} no repositório e definir a opção para as compilações. Por exemplo, o arquivo de configuração é criado em um fluxo de branch {{command|8}} do pacote {{command|foo}}, que possui conteúdo, | ||
[koji] | [koji] | ||
targets = f28 epel7 | targets = f28 epel7 | ||
Este exemplo mostra quando você executa o comando {{command|build}}, o fedpkg é capaz de enviar compilações para lançamentos, {{command|f28}} e {{command|epel7}}. | |||
Na prática, você pode especificar dois nomes de atalho {{command|fedora}} e {{command|epel}} por conveniência. O fedpkg recupera as versões atuais do Fedora e EPEL automaticamente. Portanto, se você não deseja selecionar um subconjunto de lançamentos, ou simplesmente compilar pacotes para lançamentos ativos sem saber o nome concreto do lançamento, nomes de atalho seriam úteis. Você pode especificar a compilação para {{command|rawhide}}, use o nome {{command|master}}. | |||
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | |headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Na eventualidade de você estar trabalhando com uma [[Changes/Layered_Docker_Image_Build_Service|compilação de imagem em camada de contêiner]] do Docker. | ||
fedpkg container-build | fedpkg container-build | ||
{{admon/important| | {{admon/important|Indo para produção|Este é o primeiro ponto em que você pode causar confusão real para um usuário real, portanto, use-o com cuidado. Se você estiver seguindo o exemplo e operando no Rawhide, sua compilação entrará no ar para os usuários do Rawhide algumas horas depois de executar este comando.}} | ||
{{admon/note| | {{admon/note|Usa estado do push|Ao contrário da maioria dos comandos acima, ele opera no ''estado que você enviou ao git'', não no estado local. Se você tiver problemas, certifique-se de enviar e enviar todos os patches e manipular as fontes corretamente.}} | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Isso aciona uma compilação "real" (não do zero) do seu pacote em [[Koji]]. Dependendo da versão para a qual você está compilando, ela pode ir diretamente para o [[Repositories#stable|estado ''estável'']] ou pode ter que ser executada através do [[Updates Policy|processo de atualização]]. Veja o [[Package_update_HOWTO|guia de atualização do pacote]] para mais detalhes sobre isso. O comando irá gerar uma URL onde você pode monitorar o progresso da compilação no Koji.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
* | * Envie uma atualização de pacote para a compilação mais recente (mas consulte [[Package_update_HOWTO#Updating_inter-dependente_packages|Atualizando pacotes interdependentes]] se estiver fazendo alterações interdependentes em mais de um pacote): | ||
fedpkg update | fedpkg update | ||
{{hidden|header= | {{hidden|header=Detalhes|content=Novamente, consulte o [[Package_update_HOWTO|guia de atualização do pacote]] para obter mais detalhes sobre este processo. Esta etapa não é realmente aplicável ao Rawhide, mas ilustrada aqui para integridade.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
== | == Sessão típica do ''fedpkg'' == | ||
Uma sessão típica pode ter a seguinte aparência: | |||
<pre> | <pre> | ||
fedpkg clone foo | fedpkg clone foo | ||
Line 113: | Line 113: | ||
fedpkg sources | fedpkg sources | ||
fedpkg new-sources foo-0.0.2.tar.bz2 | fedpkg new-sources foo-0.0.2.tar.bz2 | ||
gedit foo.spec # | gedit foo.spec # altere as coisas exigidas no arquivo spec. | ||
# rpmdev-bumpspec | # rpmdev-bumpspec é útil para atualizações simples de versão | ||
fedpkg mockbuild # | fedpkg mockbuild # verifica se as alterações que você fez estão corretas | ||
fedpkg diff | fedpkg diff | ||
fedpkg lint | fedpkg lint | ||
fedpkg commit -p -c # commit | fedpkg commit -p -c # faz commit e push de uma só vez | ||
</pre> | </pre> | ||
== | == Trabalhando com branches == | ||
Cada versão do Fedora é representada por um branch no repositório git. Você pode alternar entre eles desta forma: | |||
fedpkg switch-branch f{{FedoraVersionNumber}} | fedpkg switch-branch f{{FedoraVersionNumber}} | ||
fedpkg switch-branch f{{FedoraVersionNumber|previous}} | fedpkg switch-branch f{{FedoraVersionNumber|previous}} | ||
fedpkg switch-branch rawhide | fedpkg switch-branch rawhide | ||
O branch ''rawhide'' é para [[Releases/Rawhide|Rawhide]]. Você pode manter cada branch inteiramente separado, se desejar, copiando laboriosamente as alterações entre eles (contanto que você sempre permaneça dentro dos requisitos da [[Updates Policy|política de atualizações]]). No entanto, git nos fornece várias ferramentas úteis para trabalhar com branches. Aqui está um exemplo: | |||
{{#tag:pre| | {{#tag:pre| | ||
fedpkg clone bzrtools | fedpkg clone bzrtools | ||
# | # Faz algumas alterações no branch rawhide | ||
fedpkg new-sources bzrtools-2.2.tar.gz | fedpkg new-sources bzrtools-2.2.tar.gz | ||
gedit bzrtools.spec | gedit bzrtools.spec | ||
Line 136: | Line 136: | ||
fedpkg switch-branch f{{FedoraVersionNumber}} | fedpkg switch-branch f{{FedoraVersionNumber}} | ||
git merge rawhide | git merge rawhide | ||
# | # para fazer push para o repositório | ||
fedpkg push | fedpkg push | ||
}} | }} | ||
Isso irá "mesclar" as mudanças do branch ''rawhide'' (Rawhide) para o branch f{{FedoraVersionNumber}}. Os aficionados do git podem notar que este é um fluxo de trabalho um tanto incomum, mas é apropriado para o contexto de gerenciamento de pacotes. Lembre-se, após empurrar e compilar para uma versão estável ou uma versão [[Releases/Branched|em um branch]] após [[Updates Policy#Bodhi enabling|Bodhi ser ativado]], você terá que [[Package_update_HOWTO|enviar uma atualização]] antes que qualquer outro usuário do Fedora veja sua compilação. | |||
Observe que as mesclagens só funcionarão de maneira limpa, desde que as ramificações não tenham divergido anteriormente. Ou seja, se você fizer isso: | |||
{{#tag:pre| | {{#tag:pre| | ||
fedpkg clone bzrtools | fedpkg clone bzrtools | ||
# | # Faz algumas alterações no branch rawhide | ||
fedpkg commit | fedpkg commit | ||
fedpkg switch-branch f{{FedoraVersionNumber}} | fedpkg switch-branch f{{FedoraVersionNumber}} | ||
# | # Faz algumas alterações no branch f{{FedoraVersionNumber}} | ||
fedpkg commit | fedpkg commit | ||
fedpkg switch-branch rawhide | fedpkg switch-branch rawhide | ||
# | # Faz mais algumas alterações no branch rawhide | ||
fedpkg commit | fedpkg commit | ||
fedpkg switch-branch f{{FedoraVersionNumber}} | fedpkg switch-branch f{{FedoraVersionNumber}} | ||
git merge rawhide | git merge rawhide | ||
}} | }} | ||
você pode encontrar um ''merge conflict'' (conflito de mesclagem). | |||
Lembre-se de que git é um sistema ''colaborativo'' e usado como tal no gerenciamento de pacotes do Fedora. Frequentemente, você deve considerar as alterações feitas por outros ao trabalhar em um pacote e como suas alterações afetarão os outros. | |||
=== | === Resolvendo conflitos de mesclagem === | ||
Este é um tópico amplo e um tanto além do escopo deste guia, mas podemos fornecer dicas básicas. Existem outras boas referências no [http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging livro git] e no [https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line github]. | |||
Quando você executa git merge e ocorre um conflito, você pode editar os arquivos que possuem conflitos. Remova os marcadores de conflito nos arquivos e mescle as alterações manualmente. Use {{command|git diff}} ou {{command|fedpkg diff}} para inspecionar as mudanças em relação ao estado pré-conflito e verifique se você está feliz com a resolução. Então você pode enviar os arquivos com {{command|fedpkg commit}} ou {{command|git commit -a}}. git saberá se você resolveu o conflito verificando se todos os marcadores de conflito foram removidos. | |||
=== | === Usando <code>git mergetool</code> para resolver conflitos === | ||
Git | Git fornece um programa gráfico diff para ajudar a resolver conflitos. Isso pode ser útil para visualizar quais mudanças ocorreram e lidar com elas como um conjunto. | ||
{{#tag:pre| | {{#tag:pre| | ||
git config --global merge.tool meld | git config --global merge.tool meld | ||
fedpkg switch-branch f{{FedoraVersionNumber}} | fedpkg switch-branch f{{FedoraVersionNumber}} | ||
git merge rawhide | git merge rawhide | ||
# | # Conflitos ocorreram | ||
git mergetool # | git mergetool # Abre uma mesclagem mostrando uma diferença | ||
# | # de três maneiras de mesclagem, árvore de | ||
# | # trabalho e o último commit | ||
# Resolvidos todos os conflitos na interface gráfica | |||
git add CONFLICTEDFILES | git add CONFLICTEDFILES | ||
git commit | git commit | ||
}} | }} | ||
== | == Solicitando dist tags especiais == | ||
Quando uma mudança em um pacote afeta um grande número de dependências (por exemplo, todos os pacotes perl, python, ruby ou ghc), exigindo que eles sejam recompilados, pode ser melhor inicialmente fazer as compilações em um repositório especial, de modo que haja menos interrupção em Rawhide. | |||
Se você acha que tem uma atualização que se enquadra neste caso, você pode solicitar uma tag especial dist preenchendo um [https://fedorahosted.org/rel-eng/newticket tíquete de engenharia de lançamento]. Alguém da [[ReleaseEngineering|engenharia de lançamento]] provavelmente desejará discutir suas necessidades para ter certeza de que este é realmente um caso apropriado (não há problema, pergunte se você não tem certeza) e que você receberá o que precisa. | |||
== | == Dicas e truques == | ||
{{anchor|anon}} | {{anchor|anon}} | ||
=== | === Usando fedpkg anonimamente === | ||
Você pode usar o fedpkg assim: | |||
fedpkg clone --anonymous < | fedpkg clone --anonymous <algum_pacote> | ||
para verificar um pacote sem exigir identificação. Obviamente, você não será capaz de fazer nenhuma mudança neste repositório, mas é útil para não empacotadores que simplesmente desejam examinar um pacote, fazer mudanças para seu próprio uso e talvez enviar mudanças para um desenvolvedor Fedora. | |||
=== | === Nomes de branches locais === | ||
Se você usar comandos git para ramificar e fazer checkout diretamente, poderá definir os nomes de branch local que desejar. Se você usar {{command|fedpkg switch-branch}}, o padrão será a criação dos nomes usados nos exemplos acima. | |||
=== | === branch e estado atual no promtp de shell === | ||
Frequentemente, é útil saber rapidamente em qual branch você está trabalhando. Você pode adicionar essas informações ao prompt do bash com as informações [[Git_Quickref#Display_current_branch_in_bash|aqui]]. | |||
=== | === Importando um .src.rpm para atualizar === | ||
The {{command|fedpkg import}} command usually used to initially populate a git package repository from a .src.rpm that has been through the [[Package Review Process]] can also be used to update a normal working copy, if you have an old-school packaging process to which you are particularly attached. Just run {{command|fedpkg import file.src.rpm}} and it will upload new tarballs into lookaside cache, update a working copy of the last version found in git, and commit all changes. {{command|fedpkg import --help}} documents some other parameters it can accept. | The {{command|fedpkg import}} command usually used to initially populate a git package repository from a .src.rpm that has been through the [[Package Review Process]] can also be used to update a normal working copy, if you have an old-school packaging process to which you are particularly attached. Just run {{command|fedpkg import file.src.rpm}} and it will upload new tarballs into lookaside cache, update a working copy of the last version found in git, and commit all changes. {{command|fedpkg import --help}} documents some other parameters it can accept. | ||
Line 209: | Line 210: | ||
{{admon/warning|Caution!|This approach makes it harder to verify that your changes are safe and do not overwrite changes made to the package by others. For this reason, its use is not recommended.}} | {{admon/warning|Caution!|This approach makes it harder to verify that your changes are safe and do not overwrite changes made to the package by others. For this reason, its use is not recommended.}} | ||
=== | === Fazendo alterações em um branch mais antigo sem quebrar o caminho de atualização === | ||
Here is the scenario: you've built your package successfully on the ''{{FedoraVersionNumber}}'' branch, but there is a problem keeping your package from building on ''{{FedoraVersionNumber|last}}''. | Here is the scenario: you've built your package successfully on the ''{{FedoraVersionNumber}}'' branch, but there is a problem keeping your package from building on ''{{FedoraVersionNumber|last}}''. | ||
Line 227: | Line 228: | ||
Then tag and build as usual. This approach was initially discussed [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html in this mailing list thread]. | Then tag and build as usual. This approach was initially discussed [https://www.redhat.com/archives/fedora-extras-list/2006-May/msg00083.html in this mailing list thread]. | ||
=== | === Removendo uma compilação de pacote pendente para [[Releases/Rawhide|Rawhide]] ou [[Releases/Branched|Branched]] === | ||
From time to time you may want to remove a package build you submitted to Rawhide or to Branched prior to the Alpha freeze (both cases where the build would usually go out to the main [[Repositories|repository]] without further gating). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in the next release, or you realize you made a significant mistake in the build that cannot easily be corrected. | From time to time you may want to remove a package build you submitted to Rawhide or to Branched prior to the Alpha freeze (both cases where the build would usually go out to the main [[Repositories|repository]] without further gating). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in the next release, or you realize you made a significant mistake in the build that cannot easily be corrected. | ||
Line 237: | Line 238: | ||
where {{filename|foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} is replaced with the name of your package build. See {{command|koji help}} or [[Using_the_Koji_build_system|using Koji]] for more information. | where {{filename|foo-1.1.3-1.fc{{FedoraVersionNumber|next}}}} is replaced with the name of your package build. See {{command|koji help}} or [[Using_the_Koji_build_system|using Koji]] for more information. | ||
=== ssh | === Impressão digital de ssh === | ||
The recommended option is to include "<code>VerifyHostKeyDNS yes</code>" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct. | The recommended option is to include "<code>VerifyHostKeyDNS yes</code>" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct. | ||
Line 243: | Line 244: | ||
But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for src.fedoraproject.org ended up in your ~/.ssh/known_hosts file. | But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for src.fedoraproject.org ended up in your ~/.ssh/known_hosts file. | ||
=== | === Problemas para se conectar ao repositório === | ||
The ''fedpkg'' tool clones repositories using the ssh:// protocol, so this should not be a problem normally (as long as you have your ssh key). If you cloned using the ''git'' utility itself, check the {{filename|.git/config}} file to ensure the remote repository is being accessed via an ssh:// protocol, and not git://. | The ''fedpkg'' tool clones repositories using the ssh:// protocol, so this should not be a problem normally (as long as you have your ssh key). If you cloned using the ''git'' utility itself, check the {{filename|.git/config}} file to ensure the remote repository is being accessed via an ssh:// protocol, and not git://. | ||
=== | === Ele compila aqui, porque não compila lá? === | ||
Is your package building locally - even with Mock, even as a scratch build! - but not when you run {{command|fedpkg build}}? Before you get too frustrated, remember {{command|fedpkg build}} runs on the package as it exists in the upstream repository, not your local working copy. Make sure you have committed and pushed all changes and source files, and handled the lookaside cache correctly. Other issues that have been reported, are issues because of [https://bugzilla.redhat.com/show_bug.cgi?id=1179139 build/make check parallelization] and failures because of test suites that depend on operations finish on precise timing (and a busy build system may not be able to perform operations on time). | Is your package building locally - even with Mock, even as a scratch build! - but not when you run {{command|fedpkg build}}? Before you get too frustrated, remember {{command|fedpkg build}} runs on the package as it exists in the upstream repository, not your local working copy. Make sure you have committed and pushed all changes and source files, and handled the lookaside cache correctly. Other issues that have been reported, are issues because of [https://bugzilla.redhat.com/show_bug.cgi?id=1179139 build/make check parallelization] and failures because of test suites that depend on operations finish on precise timing (and a busy build system may not be able to perform operations on time). | ||
== | == Referências == | ||
* https://src.fedoraproject.org/ | * https://src.fedoraproject.org/ |
Latest revision as of 21:01, 28 February 2021
Esta página fornece algumas instruções básicas para o uso diário do sistema de manutenção de pacotes baseado em git para o Fedora. Destina-se principalmente a mantenedores de pacotes Fedora novos e atuais, mas cobre brevemente o uso anônimo somente leitura do sistema. Não é um guia para o pacote RPM em si. Algum conhecimento pré-existente sobre git pode ser útil, mas não é um pré-requisito (na verdade, o pacote do Fedora pode ser uma introdução relativamente fácil).
Você pode estar procurando ou também estar interessado em:
- Aprendendo a criar pacotes
- Se tornando um mantenedor de pacote
- Enviando atualizações de pacote
- Adicionando um novo pacote ao repositório como um mantenedor existente
- Adicionando um novo brancho de lançamento a um pacote existente
- As diretrizes de empacotamento
Instalando fedpkg e fazendo a configuração inicial
Comece instalando
com fedpkg
dnf install fedpkg
. Esta será sua interface principal para o sistema de empacotamento.
Você também deve ter uma chave ssh configurada no Fedora Accounts System para poder fazer alterações em qualquer pacote (incluindo os seus). O fedpkg espera que a chave ssh correta esteja disponível em seu chaveiro.
Antes de fazer o upload dos fontes com new-sources
e upload
e compilar pacotes no Koji (com build
por exemplo), você tem primeiro que obter suas credenciais Kerberos com kinit
. Por exemplo:
kinit [nome_de_usuário_FAS]@FEDORAPROJECT.ORG
(Mantenha FEDORAPROJECT.ORG em caixa alta)
Defina seu nome de usuário do Fedora Account System em ~/.fedora.upn
. Você pode fazer isso por meio de echo "nome_de_usuário_FAS" > ~/.fedora.upn
.
Comandos comuns do fedpkg
Esta seção lista os comandos típicos do fedpkg em um fluxo de trabalho normal, com breves descrições. Neste fluxo de trabalho, estaremos operando no branch do Rawhide do pacote.
- Faça o checkout de um pacote:
fedpkg co <nome_pacote_fontes> cd <nome_pacote_fontes>
Isso obtém uma cópia os fontes do pacote do servidor. É conhecido como sua "cópia de trabalho".
- Atualize sua cópia em local do servidor Fedora:
fedpkg pull
- Obtenha os fontes do pacote:
fedpkg sources
Isso faz um pull de todas as fontes armazenadas no "cache lookaside" (veja mais abaixo). Passos como fedpkg prep
e fedpkg srpm
farão isso se necessário, mas você pode querer uma cópia imediatamente.
- Faça suas alterações no pacote
Este não é um guia de empacotamento RPM, portanto, presumiremos que você sabe o que está fazendo aqui. Novas fontes e patches vão para o diretório da cópia de trabalho por enquanto.
- Execute o estágio "prep" (extrai fontes, aplica patches etc) dentro do diretório de checkout:
fedpkg prep
Isso é útil para garantir que seus patches sejam aplicados de forma limpa e para inspecionar a árvore de fontes, se necessário.
- Faça uma compilação local do estado atual:
fedpkg local
Este é o tipo mais simples de compilação de teste, mas geralmente é mais limpo e um teste melhor para fazer uma compilação scratch Mock ou Koji (veja abaixo).
- Faça uma compilação com mock do estado atual:
fedpkg mockbuild
Isso aciona uma compilação do Mock, se você tiver o Mock configurado corretamente. Using_Mock_to_test_package_builds pode ajudar nisso.
- Generate a .src.rpm from the current state:
fedpkg srpm
Você pode solicitar uma "scratch build" ao Koji (uma compilação de teste, que não irá para nenhum repositório) do .src.rpm gerado com o comando koji build --scratch
(consulte man koji
).
- Faça uma compilação scratch usando koji: veja sobre compilações scratch com Koji
- Verifique a alterações que você fez:
fedpkg diff
Isso é útil para garantir que você não tocou em algo por engano, se esqueceu de alterar o lançamento ou se esqueceu de incluir um changelog...
- Execute algumas verificações (rpmlint) em seu pacote:
fedpkg lint
Se você quiser colocar alguns erros rpmlint na lista de permissões e evitar que eles apareçam, você pode criar um arquivo de configuração rpmlint chamado <nome_pacote_fontes>.rpmlintrc
e será aplicado.
- Mova para stage quaisquer patches ou novos arquivos fontes para fazer commit:
git add (algum_arquivo)
O git não considera todos os arquivos no diretório de trabalho como parte do repositório git por padrão (útil, para manter outros arquivos relevantes, como a árvore de fontes). Isso diz ao git para começar a considerar esses arquivos como parte do repositório localmente. Quando você faz "commit" e "push" depois, essa mudança é comunicada ao servidor.
- Envie os novos arquivos fontes para o cache lookaside:
fedpkg new-sources
fedpkg upload
Fontes upstream "intocadas" (como tarballs de lançamento) e outros arquivos fonte maiores são armazenados no sistema de cache lookaside, não comprometidos diretamente com o git. Isso fornece armazenamento e transferência de arquivos mais eficientes. Os arquivos sources
e .gitignore
no repositório o mantém em sincronia com o cache lookaside. Toda vez que você usar fedpkg new-sources
ou fedpkg upload
, você deve se lembrar de fazer "commit" das alterações nesses arquivos.
new-sources
"começa do zero", substituindo todos os arquivos atualmente no cache lookaside - você normalmente usará este comando para muitos pacotes com apenas um único tarball de fontes, cada vez que você atualizar para uma nova versão upstream. upload
apenas adiciona o arquivo fornecido aos que já estão no cache. Lembre-se de não deixar fontes obsoletas por aí.
- Troque para um branch diferente de lançamento:
fedpkg switch-branch <f40, el6, rawhide>
Cada versão do Fedora tem seu próprio branch em cada repositório de pacotes, de forma que diferentes compilações podem ser enviadas para cada versão. Veja abaixo mais detalhes sobre como trabalhar com branches.
- Gere o changelog do git do changelog do pacote:
fedpkg clog
Este comando extrai a entrada do changelog do pacote para o arquivo clog
, então você pode usá-lo como o changelog git se quiser. Alguns mantenedores fazem uma distinção entre os dois, outros não.
- Faça commit das alterações:
fedpkg commit (-F clog) (-p) (-c)
Isso cria uma espécie de pacote, um "commit", de suas mudanças no repositório, com uma identidade única e um changelog. Outros mantenedores - e você, mais tarde - podem ver o histórico de mudanças no repositório com o "commit" como o melhor nível de detalhe. É uma boa prática usar muitos commits relativamente pequenos, cada um para um único propósito - não combine um aumento de versão com um monte de correções de espaço em branco e algumas mudanças de scriptlet tudo em um commit, crie commits separados para cada um.
O parâmetro -F clog
usará o arquivo clog
da etapa anterior como o changelog. -p
irá empurrar (veja abaixo) ao mesmo tempo que comete. -c
combina os passos clog
e commit -F clog
em um, se você quiser.
- Faça push das alterações:
fedpkg push
Isso envia todos os novos "commits" em sua cópia de trabalho local para o servidor upstream. Se você ainda está aprendendo o sistema, agora é um bom momento para fedpkg co
outra cópia do repositório em outro lugar, compare o que você obteve com sua cópia de trabalho e execute um teste de compilação nela.
- Faça uma compilação "oficial" das alterações nos últimos "pushes":
fedpkg build
- Envia compilações "oficiais" de um branch
fedpkg build
Não há diferença na linha de comando para enviar várias compilações de um fluxo de branch. Mas você precisa criar um arquivo de configuração package.cfg
no repositório e definir a opção para as compilações. Por exemplo, o arquivo de configuração é criado em um fluxo de branch 8
do pacote foo
, que possui conteúdo,
[koji] targets = f28 epel7
Este exemplo mostra quando você executa o comando build
, o fedpkg é capaz de enviar compilações para lançamentos, f28
e epel7
.
Na prática, você pode especificar dois nomes de atalho fedora
e epel
por conveniência. O fedpkg recupera as versões atuais do Fedora e EPEL automaticamente. Portanto, se você não deseja selecionar um subconjunto de lançamentos, ou simplesmente compilar pacotes para lançamentos ativos sem saber o nome concreto do lançamento, nomes de atalho seriam úteis. Você pode especificar a compilação para rawhide
, use o nome master
.
- Na eventualidade de você estar trabalhando com uma compilação de imagem em camada de contêiner do Docker.
fedpkg container-build
Isso aciona uma compilação "real" (não do zero) do seu pacote em Koji. Dependendo da versão para a qual você está compilando, ela pode ir diretamente para o estado estável ou pode ter que ser executada através do processo de atualização. Veja o guia de atualização do pacote para mais detalhes sobre isso. O comando irá gerar uma URL onde você pode monitorar o progresso da compilação no Koji.
- Envie uma atualização de pacote para a compilação mais recente (mas consulte Atualizando pacotes interdependentes se estiver fazendo alterações interdependentes em mais de um pacote):
fedpkg update
Novamente, consulte o guia de atualização do pacote para obter mais detalhes sobre este processo. Esta etapa não é realmente aplicável ao Rawhide, mas ilustrada aqui para integridade.
Sessão típica do fedpkg
Uma sessão típica pode ter a seguinte aparência:
fedpkg clone foo cd foo fedpkg sources fedpkg new-sources foo-0.0.2.tar.bz2 gedit foo.spec # altere as coisas exigidas no arquivo spec. # rpmdev-bumpspec é útil para atualizações simples de versão fedpkg mockbuild # verifica se as alterações que você fez estão corretas fedpkg diff fedpkg lint fedpkg commit -p -c # faz commit e push de uma só vez
Trabalhando com branches
Cada versão do Fedora é representada por um branch no repositório git. Você pode alternar entre eles desta forma:
fedpkg switch-branch f40 fedpkg switch-branch f39 fedpkg switch-branch rawhide
O branch rawhide é para Rawhide. Você pode manter cada branch inteiramente separado, se desejar, copiando laboriosamente as alterações entre eles (contanto que você sempre permaneça dentro dos requisitos da política de atualizações). No entanto, git nos fornece várias ferramentas úteis para trabalhar com branches. Aqui está um exemplo:
fedpkg clone bzrtools # Faz algumas alterações no branch rawhide fedpkg new-sources bzrtools-2.2.tar.gz gedit bzrtools.spec fedpkg commit fedpkg switch-branch f40 git merge rawhide # para fazer push para o repositório fedpkg push
Isso irá "mesclar" as mudanças do branch rawhide (Rawhide) para o branch f40. Os aficionados do git podem notar que este é um fluxo de trabalho um tanto incomum, mas é apropriado para o contexto de gerenciamento de pacotes. Lembre-se, após empurrar e compilar para uma versão estável ou uma versão em um branch após Bodhi ser ativado, você terá que enviar uma atualização antes que qualquer outro usuário do Fedora veja sua compilação.
Observe que as mesclagens só funcionarão de maneira limpa, desde que as ramificações não tenham divergido anteriormente. Ou seja, se você fizer isso:
fedpkg clone bzrtools # Faz algumas alterações no branch rawhide fedpkg commit fedpkg switch-branch f40 # Faz algumas alterações no branch f40 fedpkg commit fedpkg switch-branch rawhide # Faz mais algumas alterações no branch rawhide fedpkg commit fedpkg switch-branch f40 git merge rawhide
você pode encontrar um merge conflict (conflito de mesclagem).
Lembre-se de que git é um sistema colaborativo e usado como tal no gerenciamento de pacotes do Fedora. Frequentemente, você deve considerar as alterações feitas por outros ao trabalhar em um pacote e como suas alterações afetarão os outros.
Resolvendo conflitos de mesclagem
Este é um tópico amplo e um tanto além do escopo deste guia, mas podemos fornecer dicas básicas. Existem outras boas referências no livro git e no github.
Quando você executa git merge e ocorre um conflito, você pode editar os arquivos que possuem conflitos. Remova os marcadores de conflito nos arquivos e mescle as alterações manualmente. Use git diff
ou fedpkg diff
para inspecionar as mudanças em relação ao estado pré-conflito e verifique se você está feliz com a resolução. Então você pode enviar os arquivos com fedpkg commit
ou git commit -a
. git saberá se você resolveu o conflito verificando se todos os marcadores de conflito foram removidos.
Usando git mergetool
para resolver conflitos
Git fornece um programa gráfico diff para ajudar a resolver conflitos. Isso pode ser útil para visualizar quais mudanças ocorreram e lidar com elas como um conjunto.
git config --global merge.tool meld fedpkg switch-branch f40 git merge rawhide # Conflitos ocorreram git mergetool # Abre uma mesclagem mostrando uma diferença # de três maneiras de mesclagem, árvore de # trabalho e o último commit # Resolvidos todos os conflitos na interface gráfica git add CONFLICTEDFILES git commit
Solicitando dist tags especiais
Quando uma mudança em um pacote afeta um grande número de dependências (por exemplo, todos os pacotes perl, python, ruby ou ghc), exigindo que eles sejam recompilados, pode ser melhor inicialmente fazer as compilações em um repositório especial, de modo que haja menos interrupção em Rawhide.
Se você acha que tem uma atualização que se enquadra neste caso, você pode solicitar uma tag especial dist preenchendo um tíquete de engenharia de lançamento. Alguém da engenharia de lançamento provavelmente desejará discutir suas necessidades para ter certeza de que este é realmente um caso apropriado (não há problema, pergunte se você não tem certeza) e que você receberá o que precisa.
Dicas e truques
Usando fedpkg anonimamente
Você pode usar o fedpkg assim:
fedpkg clone --anonymous <algum_pacote>
para verificar um pacote sem exigir identificação. Obviamente, você não será capaz de fazer nenhuma mudança neste repositório, mas é útil para não empacotadores que simplesmente desejam examinar um pacote, fazer mudanças para seu próprio uso e talvez enviar mudanças para um desenvolvedor Fedora.
Nomes de branches locais
Se você usar comandos git para ramificar e fazer checkout diretamente, poderá definir os nomes de branch local que desejar. Se você usar fedpkg switch-branch
, o padrão será a criação dos nomes usados nos exemplos acima.
branch e estado atual no promtp de shell
Frequentemente, é útil saber rapidamente em qual branch você está trabalhando. Você pode adicionar essas informações ao prompt do bash com as informações aqui.
Importando um .src.rpm para atualizar
The fedpkg import
command usually used to initially populate a git package repository from a .src.rpm that has been through the Package Review Process can also be used to update a normal working copy, if you have an old-school packaging process to which you are particularly attached. Just run fedpkg import file.src.rpm
and it will upload new tarballs into lookaside cache, update a working copy of the last version found in git, and commit all changes. fedpkg import --help
documents some other parameters it can accept.
Fazendo alterações em um branch mais antigo sem quebrar o caminho de atualização
Here is the scenario: you've built your package successfully on the 40 branch, but there is a problem keeping your package from building on last.
Solution: make your changes in the branch and then add a digit to the very right of the release tag. There is no need to change the release in the other branches. This allows upgrades to work smoothly if the user upgrades to a newer release of Fedora.
Name: foo Version: 1.0 Release: 1%{?dist} Name: foo Version: 1.0 Release: 1%{?dist}.1
Then tag and build as usual. This approach was initially discussed in this mailing list thread.
Removendo uma compilação de pacote pendente para Rawhide ou Branched
From time to time you may want to remove a package build you submitted to Rawhide or to Branched prior to the Alpha freeze (both cases where the build would usually go out to the main repository without further gating). This could happen in a situation where a bug or issue is found in your package that will be resolved upstream in the next release, or you realize you made a significant mistake in the build that cannot easily be corrected.
You can remove the package by using Koji: koji untag-pkg f41 foo-1.1.3-1.fc41
where foo-1.1.3-1.fc41
is replaced with the name of your package build. See koji help
or using Koji for more information.
Impressão digital de ssh
The recommended option is to include "VerifyHostKeyDNS yes
" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.
But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for src.fedoraproject.org ended up in your ~/.ssh/known_hosts file.
Problemas para se conectar ao repositório
The fedpkg tool clones repositories using the ssh:// protocol, so this should not be a problem normally (as long as you have your ssh key). If you cloned using the git utility itself, check the .git/config
file to ensure the remote repository is being accessed via an ssh:// protocol, and not git://.
Ele compila aqui, porque não compila lá?
Is your package building locally - even with Mock, even as a scratch build! - but not when you run fedpkg build
? Before you get too frustrated, remember fedpkg build
runs on the package as it exists in the upstream repository, not your local working copy. Make sure you have committed and pushed all changes and source files, and handled the lookaside cache correctly. Other issues that have been reported, are issues because of build/make check parallelization and failures because of test suites that depend on operations finish on precise timing (and a busy build system may not be able to perform operations on time).
Referências
- https://src.fedoraproject.org/
- Infrastructure/Kerberos
- Package_Renaming_Process
- PackageMaintainers/PackagingTricks
- Package_update_HOWTO
- PackageMaintainers/BuildSystemClientSetup#Install_the_Client_Tools_.28Koji.29
- PackageMaintainers/MockTricks#How_do_I_use_Mock.3F
- Using_the_Koji_build_system
- Package_Review_Process
- Fedora_Release_Life_Cycle
- PackageMaintainers/Join
- Infrastructure/VersionControl/dist-git