Re: Conditional Recommends
* David Kalnischkies [2011-05-23 16:31 +0200]:
> On Sun, May 22, 2011 at 16:07, Carsten Hey <carsten@debian.org> wrote:
> > * Conflicts, Breaks, ..., Enhances:
> > - satisfied if any of the clauses is true
>
> Uhm, a Conflicts/Breaks is satisfied if all clauses are false.
This misunderstanding is caused by the unclear definition of when
a Conflicts/Breaks is "satisfied", it is (depending on the definition)
either satisfied if a package can be installed, or if a package can not
be installed.
According to De Morgen's law, the following are equal:
Given that no installed package conflicts with or breaks package X,
… package X conflicting with "A, B , C" can be installed if all are
false, otherwise it can not be installed.
… package X conflicting with "A, B , C" can not be installed if any
is true, otherwise it can be installed.
> That way you could say Conflicts = ! Pre-Depends.
> (regarding "…": Replaces doesn't fit to well in here…)
> (Enhances are reverse-suggests so i really don't understand
> why it is in the same enumeration as Conflicts/Breaks…)
"Depends: A, B, C | D" is equivalent to "Depends: A & B & (C | D)",
although the latter is not a valid syntax in Debian. The commas in
'Depends:' fields can be read as 'and'.
"Conflicts: A, B, C" is equivalent to "Conflicts: A | B | C" and the
commas in 'Conflicts:' fields can be read as 'or'. Alternatively, it
could also be read as "Pre-Depends: !A & !B & !C" - which would be very
similar to "a Conflicts/Breaks is satisfied if all clauses are false".
"Enhances: A, B, C" is equivalent to "Enhances: A | B | C" (the package
is suggested if A, B or C is installed). Given that the package with
the 'Enhances:' control field is X, "Suggests: X" in packages A, B and
C would do the same.
'Conflicts:' and 'Enhances:' both do somehow the opposite of
'Pre-Depends:' or 'Suggests:' and are both in DNF. 'Depends:' et al.
are in CNF.
Also being in DNF is the reason I put 'Enhances:' into the same
enumeration as Conflicts/Breaks.
> > If we allow logical 'and' in clauses of disjunctive fields and add
> > a field similar to 'Enhances:', but for reverse recommendations instead,
> > the above example could be written as:
> >
> > Package: A-plugin-B
> > Depends: A, B
> > Recommended-By: A & B
>
> Such a plugin 'Enhances: A' and maybe only 'Depends: B'.
> A plugin like xul-ext-firegpg (removed & discontinued upstream) enhances
> iceweasel and depends on gpg. Still, i don't think it would be a good
> idea to add something like 'Recommended-By: iceweasel & gpg'
> as this promotes this plugin nearly to priority (desktop-)standard…
Using a field 'Depends-Alternatively:' instead of alternative
dependencies via pipe symbols in the 'Depends:' field would be
a less sane solution, e.g.:
Package: foo
Depends: libc6 (>= 2.3.4)
Depends-Alternatively: debconf, cdebconf
… instead of:
Package: foo
Depends: libc6 (>= 2.3.4), debconf | cdebconf
The above would have been a very similar way to express things as the
proposed 'Recommends-When:'. The main point of my mail was to propose
a more consistent alternative to 'Recommends-When:'. I don't know the
details why gnome needs this or what exactly is planned for tdeps and
thus can't judge if 'Recommends-When:' or my alternative is a good idea
at all.
> If you want to your package manager (front-end) to suggest you to install
> the plugin if you have A, B or A & B installed then please go ahead and
> implement it in your front-end.
This would be even more wrong than implementing DPkg::Pre-Invoke and
DPkg::Post-Invoke in apt instead of dpkg.
> It will be for example interesting in stable to stable+1 upgrades:
> The dependency trees are already now very long and big, it doesn't
> help in any way if we add even more subtrees and make them
> conditional… (you want an example? udev effected kde: #610991)
I needed to upgrade epiphany-browser (or alternatively remove packages
I did not want to remove) to be able to upgrade to apt/squeeze because
of some python-libraries.
> Also, just imagine for a second we have such a field, then exactly is
> your package manager supposed to install A-plugin-B?
> Remember: New Recommends of a package are installed on a
> package upgrade - and i will come back to you at the time i am forced
> to implement logic to decide if A & B is compared to A & B & C a new
> Recommended-By clause or not…
>
> (We have such a problem already for or-groups in recommends)
> Beside that the notion of 'new' is interesting in case A-plugin-B is new
> in the archive and package A or B are upgraded (new compared to the
> last time the packages were upgraded) …
Yes, this could be "interesting" :)
> > To prevent problems with partial upgrades, a logical 'and' should only
> > be allowed in fields that do not exist in Squeeze. After Wheezy, they
> > could be allowed in 'Enhances:' too and if there are according use
> > cases, maybe even in Conflicts or Breaks.
>
> Do you have just one usecase for a 'Conflicts: A & B' which shouldn't
> be a 'Conflicts: A, B' instead?
Constructing use cases is easy (e.g., three packages diverting the same
file, although dpkg only allows two packages diverting the same file),
but I don't expect a real use case to happen. If there is no real use
case, there is no reason to allow it in Conflicts or Breaks.
> I always thought an ',' is already an 'and'.
That is exactly the point. For 'Depends:' et al., there is no doubt
that this is true. For 'Conflicts:' et al., 'Enhances:' and even
'Replaces:' (although I don't think it makes any practical difference
for the latter), parsing ',' as 'or' makes in my opinion a lot more
sense.
> … and live on without the introduction of (multi-level) nested
> and/or-groups in or-groups…
We seem to agree that nesting is really unnecessary for package
relationship fields.
> Similar thoughts for '!' - That 'Breaks' are already '! Depends' is
> clear, so in which way does it help? With the current (mis)use of
> Breaks/Conflicts i don't really want to imagine what 'Recommends: ! A'
> should tell me or the package manager… KDE4 recommends !GNOME3… will
> be fun.
In your other mail you made very clear that you consider "weak
conflicts" to be useless and I tend to agree.
The only other already mentioned use case that remains for '!' is
implication, i.e., "!A | B". Implications are the alternative to
"Recommended-{When,By}:" to solve the original problem, the former is
forwards, the latter is backwards. Without any other use case for '!',
it does not seem to matter if we choose "B {A}", "A > B", "A -> B" or
"!A | B" as syntax, given that implications in the 'Recommends:' field,
i.e., the forward variant, will be allowed.
Regards
Carsten
Reply to: