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

[Eugene V. Lyubimkin]

On 2012-07-14 04:49, Jonathan Nieder wrote:
[...]
> 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.

Ack. So, yes, it cannot be guaranteed (at least in Cupt) in all cases.
In practice the chance is low.

> 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.

To me, it's the roughly same as iii. Not always package will be tested
enough (or at all) after installation to quickly recognize missing
features. So here Recommends is fairly important as well.

>   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.

This is special-cased in Cupt (and documented in 'Soft recommends', Note 2).

>  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.
> 

Agreed.

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

Thus, so far I don't see reasons to treat i differently than iii and
iv, and therefore, no reasons to change the scoring system given ii is
special-cased already.

> 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.

Yep. I am trying to keep system simple.

> 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.

(In Cupt) you can use a pin system for it. Assign a -1000 to a package
which will outweight (by default) Recommends. This is indirectly
documented in score system introduction but maybe more visibility
needed, patches welcome.

> > 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.

Much appreciated, thanks for caring.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux developer, Debian Developer