Universe Recommends for packages in main

[Emmet Hikory]

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.

>> 2: Abolish the concept of "main" vs. "universe".  All packages
>> germinated from a given seed pot (this needs a better name) must
>> represent a closed set with regards to all of Build-Depends:,
>> Build-Depends-Indep:, Depends:, and Recommends: (although a ship seed
>> need only be a closed set of Depends:, and Recommends:)
>
> 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").
> 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?

    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.

    As an example, assume that seed X and seed Y both depend on seed
Z, if package A is in seed Z, and package B ought be installed in an
environment based on seed X, but not in an environment based on seed
Y, this ought be implemented as follows:

Package A suggests Package B (or has no explicit relationship)
Seed X contains Package B
Seed Y does not contain Package B
Seed Z contains Package A

-- 
Emmet HIKORY