yum and ATrpms: why there appear to be conflicts

[Axel Thimm]

Dear all,

before hell breaks loose and all kind of conspiracy theories dwell up
again ;)

There is a bug in yum up to yum 2.1.12 which break packages that are
split during their evolution. This affects ATrpms in a greater extend
than all other repos. This post will detail on this. Please point
people with the below mentioned symptoms to the archives of this post.

The bug in yum
==============

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144376
http://bugzilla.atrpms.net/show_bug.cgi?id=289
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140832

Consider a package foo-1.0-1 with some "bar" Provides (e.g. Provides:
bar).

A packager decides to split off some part of foo into a foo-bar
package. The new foo-bar package should provide itself "bar" and not
anymore the foo package. So this will result in two new packages,
foo-1.0-2 not providing "bar" anymore and foo-bar-1.0-2 providing
"bar".

A package resolver should detect that foo is going to be upgraded, but
the upgraded foo is missing the "bar" provides. It should then seek in
the remaining set of packages for something offering "bar" and find
foo-bar. The remaining set of packages should be the set of packages
that are not obsoleted/conflicted/upgraded by the current rpm
transaction or more precisely the rpm database after the current
transaction's ending.

The last thing is what yum does not deal with properly. It does all
the steps that are mentioned, but when it comes to seek "bar" in the
"remaining set of packages" it tests it also against the
to-be-upgraded foo-1.0-1, which should not happen. Thus yum
erroneously adds foo-1.0-1 as a dependency resolution to the upgrade
transaction to foo-1.0-2 and both new and old packages are to be
installed.

This of course leads to a conflict and the end user is presented with

> Transaction Check Error:   file /some/file conflicts between attempted installs of foo-1.0-1 and foo-1.0-2

Why it mostly affects ATrpms:
=============================

ATrpms is a repo that lays great emphasis upon compatibility, even
though the above conflicts have led many people to assume ATrpms is
not even compatible to the Fedora Core base repo.

During the last years an increasing issue between rpos was that some
repos were using libfoo.so.1 and others libfoo.so.2. There are two
ways to solve this:

o force all repos into using the same libfoo package. This is not a
  proper solution, since different repos have different
  needs.
o provide compatibility packages for shared libs like Mandrake/Debian
  are doing. The libfoo.so.1* libs get into a package called libfoo1
  and thos of libfoo.so.2* into libfoo2. Both are installable
  concurrently, so there is both forward and backward compatibility.

It is a separate discussion whether Fedora Core itself should
generally use this idom of splitting off runtime components like
shared libs into their own package and if there is interest in going
into further detail on this please don't hijack this thread to discuss
this (open up a new thread on fedora-devel or repo-coord, if you like,
I'm all for doing so!).

But for ATrpms' goals of multi-repo compatibility it is required,
otherwise a lot of repo combinations would have failed (check the
gpgme, flac etc. library so bugs that were fixed by adding ATrpms as a
repo to the set!), and will fail as soon as one repo decides to
upgrade libfoo to a version that bumps up the major lib version.

The packages potentially affected are (that's the list of package
providing compatibility packages): a52dec alsa-lib flac fontconfig
freetype gd glib2 howl libgal2 libsndfile libsoup libxml2 libxslt
lineak openh323 openh323-janus openh323-pandora openjade openquicktime
pango pwlib rpm smart xosd xvidcore

What to do
==========
o Since yum fails in its automatic dependency detection, do it
  yourself and tell yum what to do like

	   yum install foo-bar foo

  for the example above. Some packages have more than one split out
  package, so this may be cumbersome and not quite what the end user
  expects.
o Use another dependency resolver like apt (does not work on multilib
  systems) and/or smart (very early beta stadium). All resolvers
  are concurrently installable and can be used on the same system
  interchangeably (but of course not in parallel).
o avoid using repos that have split out packages. That's mainly ATrpms
  today, but any repo including updates-released may split packages
  (and has done so in the past), so that's certainly the least welcome
  solution.

According to the yum author, Seth Vidal, current yum CVS code may
already have the proper check to fix this. I had a look as I would
have packaged a CVS version of yum to offer on ATrpms to get over this
bug, but there are too many changes (looks more like yum 2.2 or yum
3.0):

# cvs -q diff -ud -r yum-2-1-12 | wc -l
1518

I hope Seth will soon find the proper fix to release a yum 2.1.13 that
deals with it.

Conclusion
==========

o Any statements on ATrpms doing a lock-in on its packages by
  providing artificial conflicts are not to be taken seriously.
o End users are quite dissatisfied that ATrpms does not work with the
  main dependency resolver of Fedora Core, and some tend to find
  comfort in reasons like the above.
o My recommendation for non-x86_64 is to use apt until this bug is
  fixed.

"So, once again, you are saying that ATrpms has no bugs, huh?"

No, ATrpms has enough bugs to deal with, only not this one :)

Thanks for reading thus far! :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20050108/9e096be6/attachment-0001.sig>