Package: amarok
Version: 1.4.6-1
Severity: important
* Ted Percival [Sun, 08 Jul 2007 14:12:46 +1000]:
> This relates to Debian bug #412464, but it has been archived so my
> follow-up bounced. Here is my proposal for solving the dependency loop
> problem.
(Since your intent was to mail the BTS, I hope it's fine that I quote
your message in a new bug report.)
> I just upgraded amarok from 1.4.4-4 in testing to 1.4.6-1 in unstable
> and neither the amarok-engines package nor amarok-xine was upgraded with
> it, leaving amarok without any working output engines. I then marked
> amarok-engines for upgrade and amarok-xine was still on 1.4.4-4.
Hello Ted, thanks for reporting this problem.
> Presumably this is a result of aptitude breaking amarok-xine's versioned
> dependency on amarok to resolve the loop. That leaves the dependency
> entirely unversioned leading to the broken installation I had.
However, this analysis is not quite correct. "Breaking the loop" does
never, ever mean breaking a versioned dependency. The package management
tools, aptitude and dpkg, will always ensure that, after all packages
are configured, the relationships between them are satisfied. Breaking a
circular dependency only has to do with the order in which packages are
configured after they are unpacked.
The problem here is that, if you look close to the 1.4.4-4 amarok-xine
package, there is no versioned dependency against amarok there! It's
only present in the 1.4.6 package. This means that when upgrading from
1.4.4, aptitude can choose to upgrade amarok alone, since amarok-xine
will still have its relationships satisfied.
This is a one-time problem which only occurs when upgrading 1.4.4-4. I
was going to say that it does not matter, since only upgrades from
testing are affected; but, oh well, I just realized 1.4.4-4 is in etch
so... many thanks for bringing this up: it needs a fix, yes.
> I've read the discussion on circular dependencies and lack of versioning
> on virtual packages, and I propose a solution: what about dropping the
> amarok-engines package and amarok-engine virtual package altogether. At
> the moment there is only the xine engine anyway. Here is my proposal for
> new depends:
> Package: amarok
> Depends: amarok-xine (= ${binary:Version})
> Package: amarok-xine
> Recommends: amarok (= ${binary:Version})
> That can easily be extended if another engine package becomes available
> by simply making the other engine(s) alternate dependencies of amarok. I
> doubt there would ever be more than 4 different engines, which is
> maintainable.
Yah, this is a good solution which I've been reluctant to adopt in the
past. I'll consider it together with other options, and will pick up one
to solve this problem.
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A celebrity is a person who works hard all his life to become well known,
then wears dark glasses to avoid being recognized.
-- Fred Allen
