Re: Conditional Recommends
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.
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…)
> 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…
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.
I don't see a good reason why the installation of A should install
"unconditional" a bunch of plugins just because i happen to have B and C
installed as it generates a bunch of new problems even if we leave
the very simple fact aside that the current dependencies are already
misused and something like that doesn't help in making it simpler…
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)
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) …
> 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? I always thought an ',' is already an 'and'.
And if i keep thinking this, the only reason for an '&' would be to
write stuff like A | (BA & BB) | C, but in the end i properly need a
glue in between BA and BB which i could package as B… or if this glue is
really not needed i could use A | BA | C, A | BB | C and live on without
the introduction of (multi-level) nested and/or-groups in or-groups…
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.
Beside that even if i could express 'Breaks' as '! Depends' i would prefer
to write them still as 'Breaks' as a small '!' easily gets lost between many
shared library dependencies. As a user its way easier to look for a Breaks
line instead of reading and parsing the complete Depends line…
Best regards
David Kalnischkies
Reply to: