[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: multlib and splitting packages

On Thu, 25 Oct 2007, Kevin Kofler wrote:

Bill Nottingham <notting <at> redhat.com> writes:
Just to note, if you fix multiarch conflicts by moving libraries to
a -libs package, your new -libs package should obsolete the older
versions of the package where the libraries came from. This is so
that yum upgrades work properly.

This hack is a bad idea, it breaks APT-RPM! (Even for non-multilib systems!)

I just tested this hack with a dummy package: I have installed a package called
multilib-obsoletes-test Version: 1, Release: 1, then put 1-2 into a test repo
(created just for this purpose), with a -libs subpackage which obsoletes
multilib-obsoletes-test < 1-2. This confuses apt-get dist-upgrade, which reacts
the following way:
The following packages have been kept back
  multilib-obsoletes-test (1-1 => 1-2)
In other words, it gets confused by the hack, and it won't update the package
at all!

Doing apt-get install multilib-obsoletes-test or apt-get install
multilib-obsoletes-test-libs by hand will do the right thing, but breaking the
dist-upgrade is bad.

An if the packager used this idiom:
Obsoletes: %{name} < %{?epoch:%{epoch}:}%{version}-%{release}
i.e. is bumping the Obsoletes with each release, then EVERY SINGLE UPGRADE of
the affected package with apt-rpm will break!

Please test your hacks with apt and smart too.

Versioned obsoletes like that is a perfectly valid dependency construct, doesn't qualify as a hack IMO. If apt and smart can't handle that they just need to be fixed...

	- Panu -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]