Processo de novo pacote para novos colaboradores

Siga Instalando Ferramentas de Empacotador.

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:

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.

Se você deseja disponibilizar construções ad-hoc para os usuários enquanto coloca o pacote nos repositórios oficiais, considere usar o Copr. É um sistema de construção automatizado e leve que pode criar repositórios usando o SRPM que você carrega. Você pode usar este espaço Copr para direcionar os revisores para seu src.rpm e especificações.

Preencha Formulário de revisão do Fedora no Bugzilla.

O processo de revisão é descrito em detalhes na página Processo de Revisão de Pacote.

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.

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).

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.

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:

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 only creates a branch for Rawhide. To request branches for other Fedora releases, see Requesting branches.

You could check out your distgit repository now, but before doing that, consider doing mkdir ~/fedora-scm ; cd ~/fedora-scm — that way, all your files are inside a single directory. Also, run ssh-add, so that you won’t have to keep typing in your key password.

Now you are ready to checkout your distgit repository from the SCM:

Refer to Using Mock to test package builds and Koji Scratch Builds for more information on testing your package. Mock uses your local system while Koji command line tool uses the Fedora build system server.

Now that you’ve checked out your (empty) distgit repository with fedpkg, cd into the repository’s main branch:

Run fedpkg to import the contents of the SRPM into the SCM:

Obviously, replace PATH_TO_SRPM with the full path (not URL) to your approved SRPM, and XXXXXX with the package review bug number.

If your package is using autochangelog, writing the bug number as specified will make the Fedora update system automatically close the bug when your package is submitted to Rawhide stable repository.

This imports into, commits, and builds only the main (Rawhide) branch.

If the push fails with this kind of message:

Then you don’t have the necessary rights to modify that package branch. View https://src.fedoraproject.org/rpms/PACKAGE_NAME to request those rights.

For more information on using the Fedora package maintenance system, see the Package maintenance guide.

Branches are f# (formerly F- and before that FC-), main, etc. So f is the branch for Fedora.

To switch to a branch first:

(e.g. f40)

Merge the initial commit from main (Rawhide), creating an identical commit in the branch:

Push the changes to the server:

Build the package:

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.

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.