[Cupt-devel] Bug#681508: cupt: please clarify how Recommends are handled

[Jonathan Nieder]

Hi,

Eugene V. Lyubimkin wrote:

> Hi Jonathan,

Thanks for a quick reply.

> On 2012-07-13 14:38, Jonathan Nieder wrote:
>> Gergely Nagy wrote[1]:

>>> Does Recommends guarantee that the platform will stay intact, unless I
>>> explicitly remove a recommended package? No?
>
> I am not sure what is "platform" here.

I should have included some context.

Gergely was discussing a hypothetical version of the gnome-core
package that Recommends instead of Depending on network-manager.

network-manager is part of what the GNOME maintainers call the "core
components" of the platform (image viewer, etc).  Some people prefer
to use an alternative tool to configure their network and this
scenario was a proposal to make the gnome-core package more useful for
these people.

By "the platform will stay intact", he meant that if network-manager
was installed to satisfy gnome-core's dependency (because this machine
is not one of those unusual setups that uses an alternative tool to
configure the network), it stays installed.

[...]
> General handling of soft dependencies is documented in [1].

Hm, thanks.

>                                                             Cupt tries
> to keep existing recommends (by default) unless something more important
> [2] pops out.

This is what I was guessing.  It is internally consistent.

>               By adjusting [3] user can adjust "importance" of
> Recommends in Cupt.

The same unsatisfied Recommends can be unimportant or very
problematic, depending on the situation:

  i.  recommender was not installed before.

      Imagined scenario: installing a package (which has a Recommends)
      with user-facing functionality for the first time.

      The Recommended package could be necessary, but if it is then the
      sysadmin will notice quickly while testing the package.  Treating
      it as a 'soft' dependency is fine.

  ii. recommender was installed before,
      recommended package was not installed before,
      recommendation is not new.

      The sysadmin has evidence that the package worked fine without
      the Recommended package, so trying to install the latter now is
      not urgent and is probably not worth the risk.

 iii. recommender was installed before,
      recommended package was not installed before,
      recommendation is new.
 
      The Recommended package could be necessary, and the sysadmin will
      not necessarily be making an effort soon to test the recommending
      package.  Satisfying the new dependency is fairly important.
 
  iv. recommender was installed before,
      recommended package was installed before.
 
      The Recommended package could be necessary, and the sysadmin will
      not necessarily be making an effort soon to test the depending
      package.  Keeping the dependency satisfied is fairly important.

It would be interesting to be able to assign different scores for case
(i), case (ii), and cases (iii) and (iv).

Unfortunately this kind of heuristic does not behave well in some
common cases:

 * package renames
 * reorganization of dependencies (Recommends moving within a
   dependency chain)

It also breaks some symmetries.

A more appealing approach would be to treat Recommends as Depends
until a sysadmin explicitly "opts out" of them.  The list of
recommender/recommended package pairs that have been opted out of,
along with a human-readable description of the reason for each, would
be stored, and these Recommends would be treated as non-dependencies
from then on.

> Finally, console front-end in wheezy notifies you [4] if existing or new
> Recommends is not satisfied in the proposed solution (only if
> installed/keeping Recommends is turned on, of course).

This is why it hasn't been more than a small inconvenience for me in
practice. :)

> Does that answer your question?

Yes, it helps.  I will mull this over more before trying to come up
with a documentation change that would help others with the same
question.

Thanks,
Jonathan