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

Re: yum/apt/up2date + distributed dependencies

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

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 Philippsen    /    Red Hat    /    nphilipp 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

Attachment: signature.asc
Description: This is a digitally signed message part

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