multlib and splitting packages

Panu Matilainen pmatilai at laiskiainen.org
Fri Oct 26 06:26:25 UTC 2007


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 -




More information about the fedora-devel-list mailing list