Re: Conditional Recommends
* Goswin von Brederlow [2011-05-22 11:55 +0200]:
> "Eugene V. Lyubimkin" <jackyf@debian.org> writes:
>
> > On 2011-05-21 21:41, Ian Jackson wrote:
> >> Simpler than this, and simpler than constructions involving negations
> >> (which would be very troublesome for the resolution algorithms), would
> >> be:
> >>
> >> Package: A-plugin-B
> >> Depends: A, B
> >> Recommended-When: A, B
Our current package relationship fields can be grouped into:
* Depends, Recommends, Suggests, ...:
- satisfied if all clauses are true
- (subset of) conjunctive normal form
- single clauses are allowed to contain logical 'or's, logical 'and's
are not allowed.
* Conflicts, Breaks, ..., Enhances:
- satisfied if any of the clauses is true
- (subset of) disjunctive normal form
- single clauses are not allowed to contain a logical 'or' nor
a logical 'and' (there were some logical 'or's in Lenny, but they
were pointless and wrong)
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
> What does that mean? Is A-plugin-B recommended when A is installed or B
> installed? Or only if A and B are installed? I assume the later. How
> would I write recommended if (A & B) | (C & D)?
Recommended-By: A & B, C & D
This also would save the need to possibly add the field
'Suggested-When:' and a reverse recommendation field similar to
'Enhances' in future.
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.
> > Putting my 'developer of unpopular package manager' on: no, no, pretty
> > please, no reverse-Recommends. Firstly, one doesn't want to scan all
> > package database to find all Recommends for the particular package,
'Enhances:', 'Provides', 'Conflicts' and 'Breaks' also require extensive
scanning in the package database.
Anyway, this subthread is all about reverse recommendations, even with
negations you would need to scan the whole repository for implications
in 'Recommends:' fields, or they would neither solve the tdep problem
nor the original problem (see the end of this mail).
> > and secondly, this is easily abusable by third-package maintainers
> > and even packages from completely different, non-Debian
> > repositories:
> >
> > Package: some-package
> > Depends: gnome
> > Recommended-When: gnome
Third-party repositories have root access on your system, see Google's
(past?) packages for things that could be done. Chrome does not abuse
it but only fiddles in your sources.list and crontab because they want
to ensure that you don't browse the internet with a browser full of
security holes (whether this is a good way to do this does not seem to
belong to this thread).
I think all this is a different problem that should be solved in
a different way, for example by a way to tell apt to ask the user before
a new package from a third party is installed or by a tools similar to
NetBSD's systrace that could be used to restrict what third party
packages are allowed to do.
> > And, still wearing the hat, negations are fairly easy to implement. If
> > we ever go for implementing conditional dependencies, negations are
> > great and powerful idea, I'd vote for them.
I agree that negations are fairly easy to implement, given that only
a subset of all possible things doable with negations (e.g., my
implication example) are allowed and if you find a sane algorithm.
Finding such sane algorithms is not that easy, at least not for all of
us and especially not if you don't spend the necessary amount of time on
thinking about it.
> Maybe this would be better?
>
> Package: A
> Recommends-If: B > C, D & E > F
>
> If B is installed then recommend C. If D and E are installed then
> recommend F.
This would _not_ be a reverse recommendation. One problem with forward
recommendations is that adding new translations for a package would
require adapting this package instead of only the translation packages.
I don't think we could handle this in a sane way if we get tdeps for
complete desktop environments (I'm not sure if this is planned).
Regards
Carsten
Reply to: