Package maintenance guide/pt-br

In other languages: English (en) 中文（中国大陆） (zh-cn) 日本語 (ja) português do Brasil (pt-br) [edit]

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 fedpkg com 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

This section lists typical fedpkg commands in a normal workflow, with short descriptions. In this workflow, we will be operating on the Rawhide branch of the package.

• Check out a package:

fedpkg co <source_package_name>
cd <source_package_name>

Details

This retrieves a copy of the package sources from the server. It's known as your 'working copy'.

• Update your checked-out copy from the Fedora server:

fedpkg pull

• Retrieve the package sources:

fedpkg sources

Details

This pulls any sources stored in the "lookaside cache" (see below for more). Steps like fedpkg prep and fedpkg srpm will do this if necessary, but you may want a copy right away.

• Make your changes to the package

Details

This is not an RPM packaging guide, so we'll assume you know what you're doing here. New sources and patches go in the working copy directory for now.

• Run the 'prep' stage (extract source, apply patches etc) within the checkout directory:

fedpkg prep

Details

This is useful for making sure your patches apply cleanly, and inspecting the source tree if you need to do so.

• Do a local build of the current state:

fedpkg local

Details

This is the simplest kind of test build, but it's usually cleaner and a better test to do a Mock or Koji scratch build (see below).

• Do a mock build of the current state:

fedpkg mockbuild

Details

This fires off a Mock build, if you have Mock configured correctly. Using_Mock_to_test_package_builds can help there.

• Generate a .src.rpm from the current state:

fedpkg srpm

Details

You can request a Koji 'scratch build' (a test build, which will not go to any repository) of the generated .src.rpm with the koji build --scratch command (see man koji).

• Do a scratch build using koji: see Koji scratch builds
• Check changes you have made:

fedpkg diff

Details

This is handy for making sure you didn't touch something by mistake, or forget to bump the release, or forget to include a changelog...

• Run some checks (rpmlint) on your package:

fedpkg lint

Details

If you want to whitelist some rpmlint errors and prevent them from appearing, you can create an rpmlint config file named <source_package_name>.rpmlintrc and it will get applied.

• Stage any small patches or new source files for commit:

git add (somefile)

Details

git does not consider all files in the working directory to be a part of the git repository by default (handy, for keeping other files around that are relevant, like the source tree). This tells git to start considering these files as part of the repository locally. When you 'commit' and 'push' later, this change is communicated to the server.

• Upload new source files to the lookaside cache:

fedpkg new-sources

Alert
This will replace the current list of source files, not add to it. See Details for more details on the lookaside cache system.

fedpkg upload

Details

'Pristine' upstream sources (like release tarballs) and other larger source files are stored in the lookaside cache system, not committed directly to git. This provides more efficient storage and transfer of the files. The sources and .gitignore files in the repository keep it in sync with the lookaside cache. Any time you use fedpkg new-sources or fedpkg upload, you must remember to 'commit' changes to those files.

new-sources 'starts from scratch', replacing all files currently in the lookaside cache - you'll typically use this command for many packages with just a single source tarball, each time you update to a new upstream version. upload just adds the given file to those already in the cache. Do remember not to leave stale sources lying around.

• Switch to a different release branch:

fedpkg switch-branch <f41, el6, rawhide>

Details

Each Fedora release has its own branch in each package repository so different builds can be sent to each release. See below for more details on working with branches.

• Generate git changelog from package changelog:

fedpkg clog

Details

This command extracts your package changelog entry to the file clog, so you can use it as the git changelog if you like. Some maintainers draw a distinction between the two, some do not.

• Commit changes:

fedpkg commit (-F clog) (-p) (-c)

Difference from git
This behaves by default like git commit -a - it stages modified files and commits all at once, though it does not add files which git is not yet tracking.

Details

This creates a sort of bundle, a 'commit', of your changes to the repository, with a unique identity and a changelog. Other maintainers - and you yourself, later - can view the history of changes to the repository with the 'commit' as the finest level of detail. It is good practice to use many relatively small commits, each for a single purpose - don't combine a version bump with a bunch of whitespace fixes and some scriptlet changes all in one commit, create separate commits for each.

The -F clog parameter will use the clog file from the previous step as the changelog. -p will push (see below) at the same time as committing. -c combines the clog and commit -F clog steps into one, if you like that.

• Push changes:

fedpkg push

Details

This sends all the new 'commits' in your local working copy to the upstream server. If you are still learning the system, now is a good time to fedpkg co another copy of the repository somewhere else, compare what you get to your working copy, and run a test build on it.

• Do an 'official' build of the latest pushed changes:

fedpkg build

• Submit 'official' builds from a stream branch

fedpkg build

Details

There is no difference in the command line to submit multiple builds from a stream branch. But you need to create a config file package.cfg in the repository and set option for the builds. For example config file is created in a stream branch 8 of package foo, which has content,

[koji]
targets = f28 epel7

This example shows when you execute build command, fedpkg is able to submit builds for releases, f28 and epel7.

In practice, you are able to specify two shortcut names fedora and epel for convenience. fedpkg retrieves current active Fedora and EPEL releases automatically. Hence, if you don't want to select a subset of releases, or just simply going to build packages for active releases without knowing the concrete release name, shortcut names would be helpful. You can specify to build for rawhide, use name master.

• In the event you are working with a Docker Container Layered Image Build

fedpkg container-build

Going into production
This is the first point at which you might possibly cause real mess for a real user, so use it with caution. If you are following the example and operating on Rawhide, your build would go live for Rawhide users some few hours after you ran this command.

Uses pushed state
Unlike most of the above commands, this operates on the state you have pushed to git, not the local state. If you have issues make sure you have pushed and committed all patches and handled the sources correctly.

Details

This triggers a 'real' (not scratch) build of your package in Koji. Depending on the release you are building for, it may go directly to the stable state or it may have to run through the update process. See the package update guide for more details on this. The command will output a URL where you can monitor the build's progress in Koji.

• Submit a package update for the latest build (but see Updating inter-dependent packages if you are making inter-dependent changes to more than one package):

fedpkg update

Details

Again, see the package update guide for more details on this process. This step is not actually applicable to Rawhide, but illustrated here for completeness.

Sessão típica do fedpkg

A typical session may look like this:

fedpkg clone foo
cd foo
fedpkg sources
fedpkg new-sources foo-0.0.2.tar.bz2
gedit foo.spec       # change the required things in the specfile.
                     # rpmdev-bumpspec is useful for simple version updates
fedpkg mockbuild     # check that the changes you made are correct
fedpkg diff
fedpkg lint
fedpkg commit -p -c  # commit and push in one go

Trabalhando com branches

Each Fedora release is represented by a branch in the git repository. You can switch between them like this:

fedpkg switch-branch f41
fedpkg switch-branch f40
fedpkg switch-branch rawhide

The rawhide branch is for Rawhide. You can maintain each branch entirely separately, if you like, laboriously copying changes between them (so long as you always stay within the Updates Policy requirements). However, git provides us with several handy tools for working with branches. Here's an example:

fedpkg clone bzrtools
# Make some changes in the rawhide branch
fedpkg new-sources bzrtools-2.2.tar.gz
gedit bzrtools.spec
fedpkg commit
fedpkg switch-branch f41
git merge rawhide
# for push into repo
fedpkg push

This will 'merge' the changes from the rawhide (Rawhide) branch to the f41 branch. git aficionados may note this is a somewhat unusual workflow, but it is appropriate to the context of package management. Remember, after pushing to and building for a stable release or a Branched release after Bodhi has been enabled, you will have to submit an update before any other Fedora users will see your build.

Note that merges will only be sure to work cleanly so long as the branches have not previously diverged. That is, if you do this:

fedpkg clone bzrtools
# Make some changes in the rawhide branch
fedpkg commit
fedpkg switch-branch f41
# Make some changes in the f41 branch
fedpkg commit
fedpkg switch-branch rawhide
# Make some more changes in the rawhide branch
fedpkg commit
fedpkg switch-branch f41
git merge rawhide

you may encounter a merge conflict.

Remember that git is a collaborative system, and used as such in Fedora package management. It is often the case that you must consider changes made by others in working on a package, and consider how your changes will affect others.

Resolvendo conflitos de mesclagem

This is a large topic and somewhat beyond the scope of this guide, but we can give basic pointers. There are other good references in the git book and at github.

When you git merge and a conflict occurs you can edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Use git diff or fedpkg diff to inspect the changes against the pre-conflict state and verify you are happy with the resolution. Then you can commit the files with fedpkg commit or git commit -a. git will know if you have resolved the conflict by checking that all the conflict markers have been removed.

Usando git mergetool para resolver conflitos

Git provides a graphical diff program to help resolve conflicts. This can be handy for visualizing what changes have occurred and dealing with them as a set.

git config --global merge.tool meld
fedpkg switch-branch f41
git merge rawhide
# Conflicts occurred
git mergetool            # Opens up a meld showing a three way diff of 
                         # the merge, working tree, and the last commit
# Resolved all the conflicts in the GUI
git add CONFLICTEDFILES
git commit

Solicitando dist tags especiais

When a change to a package affects a large number of dependencies (e.g. all perl, python, ruby or ghc packages), requiring them to be rebuilt, it may be better to initially do the builds in a special repository, so that there is less disruption in Rawhide.

If you think you have an update that falls under this case you can request a special dist tag by filing a release engineering ticket. Someone from release engineering will likely want to discuss your needs to make sure this is really an appropriate case (it's OK ask if you aren't sure) and that you get what you need.

Dicas e truques

Usando fedpkg anonimamente

You can use fedpkg like this:

fedpkg clone --anonymous <somepackage>

to check out a package without requiring identification. Obviously, you will not be able to push any changes to this repository, but it is useful for non-packagers who simply want to examine a package, make changes for their own use, and perhaps submit changes to a Fedora developer.

Nomes de branches locais

If you use git commands to branch and checkout directly, you can define whatever local branch names you want. If you use fedpkg switch-branch, it will default to creating the names used in the examples above.

branch e estado atual no promtp de shell

It is often helpful to know what branch you are working on at a glance. You can add this information to your bash prompt with the information here.

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.

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

Use this carefully!
This should only be done on the same day of the build, before it is included in a compose. If your build was already included in a compose you must not untag it! Check the Release Engineering Dashboard to get the starting time of the last compose.

You can remove the package by using Koji: koji untag-pkg f42 foo-1.1.3-1.fc42

where foo-1.1.3-1.fc42 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