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

Re: status of circulars dependencies in unstable

On Sun, 6 Jun 2010 18:53:04 +0200
Rene Engelhard <rene@debian.org> wrote:
> On Sun, Jun 06, 2010 at 06:29:01PM +0200, Josselin Mouette wrote:
> > Le dimanche 06 juin 2010 à 18:06 +0200, Petter Reinholdtsen a
> > écrit :
> > > [Bill Allombert]
> > > > Dear developers,
> > > > Today circular dependencies in unstable reached an all-time low.
> > > 
> > > Very good to hear.  If only we could get it down to zero, piuparts
> > > would be able to test all the packages and a more deterministic
> > > package installation order would be ensured.  :)
> > 
> > Indeed that would help a lot.
> > 
> > It is probably too late for squeeze, but how about forbidding it
> > into the policy after the release?
> No. Besides that I think it would be bad to forbid correct
> dependencies it would break some subpolicies. (I have the
> cli-uno-bridge <-> libuno-cppuhelper1.0-cil one in mind, see #495748).
> No, that's not the way to go, IMHO.

That bug doesn't explain why the second half of the circular dependency
is required:
libuno-cli-cppuhelper1.0-cil 	:Depends: cli-uno-bridge

Isn't there a way of moving files between packages to prevent the
circular dependency?

The bug report doesn't explain why this needs to be a Depends: either -
it could be a Recommends AFAICT. To quote the report, "which for some
stuff needs...." - the definition of a Recommends in my book. If
packageA is more than slightly usable without packageB being unpacked,
there is no need for a Depends:, it should be a Recommends.

It's already part of Policy 7.2 - the problem isn't just to do with
your two packages, it's about reverse dependencies of those packages.

Policy can be improved and clarified but that's what will probably have
to wait until after Squeeze.

For one thing, it makes things hard for people who want to have full
control over which packages are installed - including ignoring

Consider this example:

PackageA does not need libfoo, it just needs bin-bar. bin-bar depends on
libfoo in a normal shlibs:Depends manner, so, fair enough, libfoo is

PackageB does not need bin-bar, just libfoo and has been very carefully
designed to be minimalist and only uses a fraction of the symbols from
libfoo - why force bin-bar to be installed when it is completely

If it's that hard, make a new package - PackageC - which contains those
elements which cause the library to depend on files in the binary
package. The slimmed down binary then just depends on the library which
depends on the new package. This would still mean that anything which
only depends on the library would only need the library and the new

Removing circular dependencies IS the way to go in Debian IMHO. It's
long overdue, even for perl|perl-modules and g++|libstdc++.


Neil Williams

Attachment: pgpV0WFlRpLem.pgp
Description: PGP signature

Reply to: