yum/apt/up2date + distributed dependencies

[Nils Philippsen]

On Mon, 2003-10-20 at 14:25, Dan Morrill wrote:
> Since up2date now supports multiple repositories, this opens a question
> in my mind:  what happens when you have distributed dependencies?
> 
> Here's a specific (though partially contrived) example:
> 
> - Install xmms-42.0 from Fedora Core
> - Install xmms-mp3-42.0 from freshrpms because you live in a jurisdiction
>    where you are legally able to do so
> 
> What happens when Fedora Core releases xmms-42.1?
> 
> FC doesn't include xmms-mp3, but xmms-mp3 depends on xmms. Hence, the
> upgrade of xmms will fail so as not to break xmms-mp3.

The problem in that case is not primarily that one repo depending on
another one lags behind, but an over-zealous dependency in the xmms-mp3
package -- it should not require "xmms = %{version}-%{release}". A
proper solution could be for the xmms RPM to provide something like
"plugin-ABI(xmms) = <someepoch>:<someversion>" and xmms-mp3 to depend on
that. If upstream doesn't "officially" or reliably stick to a plugin
API/ABI, <someversion> could still be an integer incremented with each
non-backwardly-compatible API/ABI change and <someepoch> covering
changes in e.g. the compiler that change the ABI without any upstream
change.

In this particular case, perhaps depending on libxmms.so.1 would be a
first step into the right direction, provided that it actually
represents the plugin API of XMMS (I don't know if it does).

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031020/314e57e0/attachment.sig>