Universe Recommends for packages in main

[Colin Watson]

On Thu, Jun 26, 2008 at 02:23:42AM +0900, Emmet Hikory wrote:
> Michael Bienia wrote:
> > On 2008-06-25 10:02:48 +0900, Emmet Hikory wrote:
> >> 1: All packages in main must represent a closed set with regards to
> >> all of Build-Depends:, Build-Depends-Indep:, Depends:, and
> >> Recommends:.
> >
> > Given that Recommends: should be understood as weak Depends: it looks
> > like the correct solution that Recommends: should be all in main. But I
> > fear that we need to introduce Ubuntu changes to several main packages
> > just for this, which we need to merge every time (and check if perhaps
> > one of the Recommends: moved in between to main).
> 
>     Excellent point, although anything which causes the installation
> CDs to not be Recommends-complete results in a system that differs
> from that caused by installation of the relevant meta-package, with a
> huge impact on our QA and documentation practices.  Considering that
> policy 3.8.0, section 7.2 states "The Recommends field should list
> pacakges that would be found together with this one in all but unusual
> installations", I suggest that not having an installation
> Recommends-complete is likely incorrect, and has increasing
> behavioural implications on the running system.  As a result, the
> avoidance of such merging requirements imposes a large MIR burden.

I very much agree with Emmet here. In my opinion as germinate
maintainer, germinate should match apt's default behaviour as closely as
possible in terms of which dependency arcs it chooses to follow. I plan
to change germinate fairly soon to follow Recommends by default.

Yes, this means that a number of packages will need to be adjusted where
we feel that Recommends are inappropriate and should be Suggests
instead. I don't actually think that this will be all that many, though;
it's certainly a far smaller delta than many others that we continue to
maintain.

> > I don't know if it's possible but what about the case where package A
> > recommends B which isn't in the "standard" seed but in an other seed
> > which "depends" on the "standard" seed (e.g. "desktop" or "xubuntu").
          ^^^^^^^^^^^^

I prefer "inherits from" to avoid the obvious terminological
difficulties here.

> > So in the case of a "desktop" installation A should recommend B (and
> > install it). But what about a "server" installation where B isn't
> > included in the seed? Should A still recommend B?

This is slightly confused, because (1) seeds generate
dependency-complete outputs, and I think you're thinking more of the
outputs than the unexpanded seeds here, and (2) A cannot simultaneously
recommend and not recommend B.

I intend that A recommending B will cause B to be pulled into all the
outputs for seeds where A is present.

>     If we assume seeds to generate recommends-complete sets of
> packages, then we can consider two differenct cases:
> 
> 1) Package B should generally be installed along with Package A
> 2) In the context of flavour C, Package B should be installed along
> with Package A
> 
>     In the first case, the package should express the relationship
> with Recommends; in the second case, the seed should express the
> relationship by inclusion of both packages.

Agreed.

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]