Hi, 2007 m. July 8 d., Sunday, jūs rašėte: > > 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: I would rather leave virtual engine package. Although it's unlikely that there will ever be more than 3 usable amarok engines in Debian, virtual package looks cleaner than cluttering Depends field with hardcored alternatives (even 3). However, if dropping the virtual package turns out to be a cleaner solution for more severe problems (e.g. circular dependences), I'll do it.
> >
> > 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.
In my opinion, this solution fails to meet Policy 7.2:
<quote>
Depends
This declares an absolute dependency. A package will not be configured unless
all of the packages listed in its Depends field have been correctly
configured.
</quote>
i.e. it's circular dependency so dpkg can't clearly figure out which package
(either amarok or any of its engines) to configure first.
--
Modestas Vainius <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part.
