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

Re: New package dependency field format

On Wed, Sep 10, 2003 at 09:32:46AM -0400, Joe Moore wrote:
> On Fri, Sep 05, 2003 at 03:21:16AM +1000, Anthony Towns wrote:
> > > That still sounds redundant, and can be currently expressed with
> > > Depends: foo, foo | bar
> > What is equivalent is:
> > 	foo Depends: foo | foobar-dummy
Err, that should be bar, sorry.

> > 	foobar-dummy Conflicts: bar
> How would you deal with the conflict that arises when bar is later installed?

You'd uninstall foobar-dummy.

> Do you have to check the dependencies for all packages whenever you install
> something just in case they add a new dependency?

You have to check the Conflicts: for all installed packages whenever you try
to install a new package now, yes.

> Package baz requires foo only if bar is installed.
> I don't have bar installed.
> I install baz.  foo not required, bar still not installed.
> I install bar for another purpose a couple of weeks later.
> How and when does dpkg notice that baz is now inconsistant?

	baz Depends: baz-no-bar | bar, baz-no-bar | foo
	baz-no-bar Conflicts: bar

dpkg will notice that baz-no-bar Conflicts: with bar as soon as you
try to install it. At that point you'll have to uninstall baz-no-bar;
at which point apt will tell you you need to install both bar and foo,
or remove baz. dpkg won't complain too much unless you use --audit.

The maths way of saying this is:

	a Depends: b | ~c

=>	a => (b | ~c)
=>	~a | (b | ~c)
=>	~a | b | ~c
=>	(~a | b | d)  and (d => ~c)
=>	(~a | (b | d)) and (d => ~c)
=>	a => (b | d)  and (d => ~c)

=>	a Depends: b | d; d Conflicts: c

A more specific example is something like wanting to say "You should
install foo-doc-de if you have foo and locale-de installed". This can
be expressed by:

	foo Depends: foo-doc-de-notneeded | foo-doc-de
	foo-doc-de-notneeded Depends: foo
	foo-doc-de-notneeded Conflicts: locale-de

If you need to express these things through dependencies, using techniques
that work with existing tools -- even if it's a kludge -- is much better
than adding incompatible new syntax and breaking all the existing tools
that try to work with dependencies.

But it's not clear that this should be a dependency at all though; other
options are things like having dpkg/apt frontends automatically select
"related" packages, so that you can say "I want documentation", and
automatically have "foo-doc" be selected whenever you select "foo"; or
"I want development libraries" and get "libfoo-dev" with every "libfoo";
or "I want Perl and Python development libraries" and get "libfoo-perl"
and "python-foo" for every "libfoo" you install. This has the benefit that
you're not using --force arguments to dpkg or breaking apt's algorithms
whenever you want to have an exception to the site default. It does
require standardised package naming schemes, but that's desirable in
any case, and mostly already done.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

Australian DMCA (the Digital Agenda Amendments) Under Review!
	-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda

Attachment: pgpmKk4IdH9Q2.pgp
Description: PGP signature

Reply to: