* David Kalnischkies [2011-05-23 16:31 +0200]: > On Sun, May 22, 2011 at 16:07, Carsten Hey <cars...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110523210125.ga22...@furrball.stateful.de