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

Re: Can I simulate a weak conflict?



On Thu, 28 Jul 2005, skaller wrote:
On Wed, 2005-07-27 at 11:22 -0600, Bruce Sass wrote:
<...>
Can dpkg/apt/etc. be tweaked to automatically Provides: no-* ?

Two methods, one is not tenable:

(a) X conflicts with no-X implicitly

no-X doesn't really "conflicts" with X, there is an exclusive-or relationship between them and it just happens that a "conflicts" in the pkg DB conveys that relationship - it is two different worlds though and the implications of a conflict may be too much.

Consider this...
How does one conflict with something which is not installed.

(b) When Y depends on no-X, if Y is installed, no-X is
 synthesised and installed too if it doesn't exist,
 (and conflicting with X to prevent X being installed).

I don't think that would be necessary...

The dummy installation is mandatory because here
is the alternative, which is not tenable:

When installing X, scan all installed packages
to see if there is a dependency on no-X, if so
there is a conflict.

...because the tools could get by with keeping track of no-X only if some other package explicitly took an interest in no-X.

This is untenable because it requires scanning all
packages in your local database, whereas installation
of a package should only require looking up the
listed dependencies.

Agreed, if it is required. Since it is not so much the value of no-X (that is trivially "true" for all X's which are not installed and installing a Y which depends on no-X does not change the value) but rather the fact that some package depends on no-X which is important, so lets only keep track of that. Assuming the list of no-X's is small, I would expect the overhead placed on installing an arbitrary X to be minimal.

aside: a DB which holds data about packages which should not be installed is likely to open up some possibilities, eh.

The reason a logical 'X isn't installed' does not
work is that you could install Y, which depends
on no X, and then just install X. Now Y is silently
broken by a package that knows nothing about Y.

solved above by keeping track of packages which should not be installed

The first technique works 'as if for each package X,
either X or no-X was installed' and is the same
as for the manual installation of a no-X package
except it is handled by apt automatically and doesn't
require any no-X package in the repository (but
one must still be physically entered into your
local database).

I hadn't considered how to map the no-X (or maybe more accurately, !X) information into the language of package dependencies, maybe:

Pre-Depends: !some-package (versioned)

If the test fails installation is skipped (or handled, somehow, depending on the tool, frontend, etc.), if !some-package is true then some-package is included in the new no-status DB.


- Bruce



Reply to: