James Antill (illiterat) wrote,

Not putting all your pkgs in one repo. (yum edition)

As you create packages for private use, the question will eventually come up "where do I put these". The choice is obvious for the first package, just create a repo. (using createrepo -d) and distribute the my.repo file. However as you create more packages the answer should expand to having multiple repos. Different package managers have a different ideas about what should go inside a single repository, and the corollary to that is if you take the "best practice" for some other package manager and apply it to yum the results might not be all they could be. This posting will try and lay out the best practises for yum (3.2.z), and some of the reasons for them.

Probably the most common problem I see is people who think "yum-priorities" and/or "yum-versionlock" is a good solution to their problem, it is not. Another warning sign is the use of exclude and/or includepkgs, which are just a faster version of the above. While those plugins adds certain features that make certain things possible, needing those features is always a sign that you've got the separation of packages into repositories wrong (or something is just plain broken).

One of the least worst problems is they are not scalable, the basic implementation gets all the "good" packages and then excludes all the "bad" packages. However the real problems start due to the shortcuts they take so they can be faster, for instance if pkgA depends on pkgB and only pkgB is a "good" / "bad" package then pkgA will now either having a missing dependency or will end up running with something it wasn't built with/for. As more packages are added to the repositories it's more likely problems will arise.

The correct solution to problems that suggest yum-priorities, having packages that are an extension of an upstream and packages that override others in the upstream, is to split your one repository into more than one. Here is a quick list of reasons you'd want more than one repository:

  • debuginfo:

    Debuginfo packages are large, and rarely needed. Also the yum-utils command, debuginfo-install, will automatically install them correctly if they are in a repo. with the same base repoid but with "-debuginfo" appended.

  • source:

    Source packages also tend to be large, and also rarely needed. In this case the yum-utils command, yumdownloader --source, will automatically download them correctly if they are in a repo. with the same base repoid but with "-source" appended.

  • Binary architectures:

    Putting .i386 and .ppc packages in the same repository is a little more convenient on the server side, but it means every action on the client side has to filter out all the packages of the wrong architecture. Also, it means you have almost no control over multilib issues on the client (.i386 and .x86_64 on a x86_64 machine, for example).

  • stability or freshness:

    While yum can install old packages, and move to newer packages that aren't the latest versions, it's support for this is much weaker than the more expected case of installing or moving to the latest available package (for instance dependencies of installed packages will currently always move to the latest available). So it makes sense to have myrepo-release, myrepo-stable, myrepo-rc, myrepo-testing, myrepo-development type repositories.

    Yum's ability to allow you to easily temporarily add a repository with --enablerepo=myrepo-testing (or use yum-aliases to create a synonym) or even use yum-tmprepo, makes this a much more viable alternative than it otherwise would be. As this means you can have several repositories that are configured to be disabled but then you temporarily enable them (to install a single package etc.).

  • enhances or overrides:

    Sometimes you want extra packages because they are not available elsewhere and sometimes you want custom "upstream" packages (for specific local patches etc.). You should not mix these two types of packages, this also makes it easier to answer questions like "Do our extension packages rely on any of our custom upstream packages".

One of the main things that isn't listed above is "security updates" vs. "bugfix updates", this type of update is often split in other package managers. However in yum you should just create (or generate) updateinfo.xml data for the repository, and then use the yum-security plugin to select security updates (or fixes for specific CVE/BZs/etc.)

Tags: best practise, package management, yum
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded  

  • 0 comments