Processo de novo pacote para novos colaboradores
Esta é uma versão longa do processo de novo pacote, contendo mais detalhes para que novos colaboradores possam acompanhá-lo mais facilmente. Além disso, a etapa obrigatória depatrocínio está incluída.
Verificar se o pacote já existe
Se algum software útil ainda não estiver incluído no Fedora, você poderá enviá-lo como um novo pacote. O pacote que você está enviando pode ser de qualquer projeto livre e de código aberto.
Antes de criar seu pacote, certifique-se de que o software ainda não esteja no repositório Fedora:
-
Verifique se o pacote já existe pesquisando em Fedora Packages.
-
Pesquise no Review Tracker os pacotes em revisão.
-
Verifique pacotes órfãos ou retirados que precisam de novos mantenedores.
-
Esteja ciente dos itens proibidos.
Criar um pacote
-
Se você não sabe como criar um pacote RPM, consulte Tutorial de Empacotamento.
-
Certifique-se de que seu pacote atenda às Diretrizes de Empacotamento e Diretrizes de Nomenclatura de Pacotes.
-
Esteja ciente das Diretrizes de Revisão de Pacotes (elas serão usadas durante a revisão do pacote).
-
Certifique-se de que seu pacote construa com sucesso. Isto é surpreendentemente importante porque um número significativo de submissões não o funciona.
Enviar seu pacote
Envie seus arquivos SRPM e SPEC para a Internet em algum lugar para que outros possam obtê-los. Isso pode ser acessível em qualquer lugar por meio de uma URL, mas é importante que os arquivos sejam diretamente acessíveis, e não escondidos atrás de algum serviço que faça as pessoas esperarem para baixar coisas ou redirecionar através de páginas publicitárias.
Recomenda-se o uso de Copr. Ele permite a criação de repositórios usando o arquivo src.rpm ou spec, que pode ser compartilhado com os revisores. Também permite criar construções automáticas a partir desses arquivos e distribuir os resultados.
Primeiro você precisa fazer login em Copr, você pode usar sua conta do Fedora.
Em seguida, siga este tutorial para construir o projeto. Durante a etapa "New Build" (nova construção), você precisa enviar seu código-fonte. Você pode escolher o que melhor se adapta às suas necessidades. No entanto, se não tiver o código-fonte carregado em outro lugar, selecione a opção "Upload" (enviar) e, na seção "Provide the source" (fornecer a fonte), clique no botão Choose File… para selecionar um arquivo. Agora, na próxima seção, você precisa especificar os Chroots e outras opções de construção, selecionar pelo menos um chroot fedora-rawhide e ajustar outras configurações conforme necessário.
Após a conclusão da compilação, você pode usar os seguintes links para o processo de revisão:
-
Link para o arquivo spec: acesse seus pacotes copr, clique no nome do seu pacote e, em informações gerais, procure seu repositório dist-git. Encontre o arquivo Spec nesta árvore de repositórios e copie o link, mas substitua a parte tree da URL pela string plain e use-a para o envio da revisão.
-
Link para o arquivo SRPM: nas suas construções copr, clique no id da sua última construção bem-sucedida e, em informações gerais, procure o link chamado diretório. Aqui, acesse a pasta /srpm-build/sue_id_construção/ e copie a URL do arquivo src.rpm para seu envio para revisão.
Criar sua solicitação de revisão
-
Antes de enviar sua solicitação, certifique-se de que não haja uma solicitação anterior para o mesmo pacote. Há uma caixa de pesquisa conveniente na página de status de revisão de pacotes.
-
Certifique-se de colocar o nome do pacote (excluindo números de versão e lançamento) no campo
Review Summary, junto com um breve resumo do que é o pacote. -
Coloque uma descrição do seu pacote (normalmente, pode ser a mesma coisa que você colocou na especificação
%description) no campoReview Description. Inclua as URLs de seus arquivos SRPM e SPEC. -
Explique no ticket que este é seu primeiro pacote e você precisa de um patrocinador. Além disso, inclua qualquer informação que possa ajudar os possíveis patrocinadores. Se você esteve ativo em outro trabalho de revisão, inclua links. Se você é o mantenedor original, não se esqueça de dizer isso.
-
Para ganhar pontos extras, inclua um link para uma construção de koji bem-sucedida para que todos saibam que você fez todo o dever de casa.
O processo de revisão é descrito em detalhes na página Processo de Revisão de Pacote.
Informar ao upstream
O Projeto Fedora prefere se Manter próximo aos Projetos Upstream. Informe aos desenvolvedores que você está empacotando o software. Você pode fazer isso enviando um e-mail apresentando-se e apontando a solicitação de revisão. Isso prepara o terreno para conversas futuras. Eles geralmente anunciam o fato de que seu software agora faz parte do Fedora ou podem querer lhe informar sobre bugs importantes na versão existente, roteiros futuros, etc.
Fique atento aos feedbacks
Acompanhe o relatório do Bugzilla para seu primeiro pacote. Você deverá receber notificações de alterações por e-mail. Corrija quaisquer questões bloqueantes apontadas pelo(s) revisor(es).
Obtenha patrocínio
Quando o pacote for dado como APPROVED pelo revisor, você deverá obter separadamente o patrocínio de membro para fazer o check-in e construir seu pacote. O patrocínio não é automático e pode exigir que você participe de outras formas para demonstrar sua compreensão das diretrizes de empacotamento. A chave para ser patrocinado é convencer um membro patrocinador existente de que você entende e segue as diretrizes e processos do projeto.
Consulte Como ser patrocinado para o grupo packager para obter mais informações sobre o processo de se tornar patrocinado.
Seu patrocinador pode adicioná-lo ao grupo packager. Você deverá receber um e-mail de confirmação do seu patrocínio.
Adiciona o pacote ao sistema gerenciamento de código-fonte (SCM) e defina o proprietário
Antes de continuar, sincronize sua conta fazendo login em Fedora Package Sources usando suas credenciais FAS.
Se você está se tornando o mantenedor de um novo pacote, em vez de ser um comantenedor, use fedpkg para solicitar um novo repositório git para o seu pacote. O subcomando é fedpkg request-repo que inclui texto de ajuda para configurar o token da API do Pagure que o comando requer. Ao criar sua chave de API, escolha alternar tudo para as ACLs. Você deve especificar o nome do repositório e revisar o número do bug. Por exemplo:
fedpkg request-repo python-prometheus_client 1590452
A solicitação será analisada e processada automaticamente. Após o processamento, você terá acesso para confirmar e construir o pacote. Caso a automação não funcione, você pode relatar o problema para rastreador de problemas do Toddlers.
fedpkg request-repo cria apenas um branch para Rawhide. Para solicitar branches para outras versões do Fedora, veja Solicitando branches.
Fazer checkout do repositório distgit
Você poderia fazer o checkout do seu repositório distgit agora, mas antes disso, considere executar mkdir ~/fedora-scm ; cd ~/fedora-scm — dessa forma, todos os seus arquivos estarão em um único diretório. Além disso, execute ssh-add para não precisar ficar digitando a senha da sua chave.
Agora você está pronto para fazer checkout do seu repositório distgit do SCM:
fedpkg clone <seu_pacote>
Testar seu pacote
Consulte Usando o Mock para testar compilações de pacotes e Scratch Builds do Koji para obter mais informações sobre como testar seu pacote. O Mock usa seu sistema local, enquanto a ferramenta de linha de comando Koji usa o servidor do sistema de construção do Fedora.
Importar, fazer commit e construir seu pacote
Agora que você fez o checkout do seu repositório distgit (vazio) com fedpkg, faça cd no branch principal do repositório:
cd <nome_pacote>
Execute o fedpkg para importar o conteúdo do SRPM para o SCM:
fedpkg import <caminho_do_srpm>
# Revise as alterações, pressione 'q' para parar; Reverta com: git reset --hard HEAD git commit -m "Initial import (fedora#XXXXXX)." git push fedpkg build
Obviamente, substitua CAMINHO_PARA_SRPM pelo caminho completo (não URL) para seu SRPM aprovado e XXXXXX pelo número do bug de revisão do pacote.
Se o seu pacote estiver usando autochangelog, escrever o número do bug conforme especificado fará com que o sistema de atualização do Fedora feche o bug automaticamente quando o seu pacote for enviado ao repositório estável do Rawhide.
Isso importa, faz commit e constrói apenas o branch main (Rawhide).
Se o push falhar com este tipo de mensagem:
W access for why DENIED to YOUR_ACCOUNT fatal: The remote end hung up unexpectedly Could not push: Command '['git', 'push']' returned non-zero exit status 128
Então você não tem as permissões necessários para modificar esse branch de pacote. Consulte https://src.fedoraproject.org/rpms/NOME_DO_PACOTE para solicitar essas permissões.
Para obter mais informações sobre o uso do sistema de manutenção de pacotes do Fedora, consulte o Guia de manutenção de pacotes.
Update Your Branches (if desired)
Branches are f# (formerly F- and before that FC-), main, etc. So f is the branch for Fedora.
To switch to a branch first:
fedpkg switch-branch <branch>
(e.g. f42)
Merge the initial commit from main (Rawhide), creating an identical commit in the branch:
git merge rawhide
Push the changes to the server:
git push
Build the package:
fedpkg build
If there is another branch to work with repeat To switch to a branch and import and commit to each branch.
If everything goes well, it should queue up your branch for building, the package will cleanly build, and you’re done!
If it fails to build, the build system will send you an email to report the failure and show you to the logs. Commit any needed changes to git, bump the SPEC release number, and request a new build.
Submit Package as Update in Bodhi
The Fedora update system called Bodhi is used for pushing updates, classifying packages etc. You do not need to submit updates for Rawhide (main) manually because these are automatically created for you when the build completes. For all other branches, you must manually push updates for all builds that you would like to make available to users.
You can push an update using Bodhi via the command line using this in each branch:
fedpkg update
It is often easier to complete builds for all your branches and then push a single update using the Bodhi web interface. Bodhi is smart enough to split your update into individual updates, one for each Fedora release branch.
You can also select multiple builds from different packages to include in a single update using the web interface. This is useful when you would like to push linked builds, for example: an application package and its dependencies that are necessary for it to run correctly.
Please see the Package Update Guide for more details.
Make the package available in "comps" files
If appropriate for the package, make it available in "comps" files so that it can be selected during installation and included in dnf package group operations. See How to use and edit comps.xml for package groups for more info.
Watch for updates
Fedora has the infrastructure available for monitoring new upstream releases of the software you are packaging. Refer to Upstream Release Monitoring for more details.
Want to help? Learn how to contribute to Fedora Docs ›