Universe Recommends for packages in main

[Chris Cheney]

On Fri, 2008-07-04 at 12:31 +0100, Colin Watson wrote:
> On Wed, Jul 02, 2008 at 02:46:44PM +0100, Colin Watson wrote:
> > At present the number of packages pulled into (e.g.) the desktop CDs as
> > a result of following Recommends is rather more substantial. However, I
> > think this is mostly because language-pack-*-base recommends
> > language-support-*, and once that's fixed most of this should go away.
> > The list follows for completeness, but don't panic about it just yet.
> [...]
> >   gij
> >   openoffice.org-filter-binfilter
> >   openoffice.org-java-common
> >   openoffice.org-writer2latex
> 
> When taken together with their own dependencies and recommendations,
> these packages are pretty huge, and are pulled in solely due to a
> Recommends from openoffice.org-writer. Chris, would it be acceptable to
> demote these to a Suggests?

Obviously we could remove them, but they definitely fall under what is
considered 'Recommends' level packages for OpenOffice.org...

Java - lots of OOo functionality requires Java
----
gij
openoffice.org-java-common

OOo 1.x filters
---------------
openoffice.org-filter-binfilter

Latex output
------------
openoffice.org-writer2latex

This points to a question being: Why are we trying to include Recommends
on the cd at all since it is nearly oversized already. What goes into
Recommends are fairly clearly defined in policy, so why are we trying to
water down Recommends to make it all fit on the cd? Is it to satisfy a
checklist? ;-)

Chris

===

Section 7.2

7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances,
Pre-Depends
Packages can declare in their control file that they have certain
relationships to other packages - for example, that they may not be
installed at the same time as certain other packages, and/or that they
depend on the presence of others.

This is done using the Depends, Pre-Depends, Recommends, Suggests,
Enhances, Breaks and Conflicts control file fields.

These seven fields are used to declare a dependency relationship by one
package on another. Except for Enhances and Breaks, they appear in the
depending (binary) package's control file. (Enhances appears in the
recommending package's control file, and Breaks appears in the version
of depended-on package which causes the named package to break).

A Depends field takes effect only when a package is to be configured. It
does not prevent a package being on the system in an unconfigured state
while its dependencies are unsatisfied, and it is possible to replace a
package whose dependencies are satisfied and which is properly installed
with a different version whose dependencies are not and cannot be
satisfied; when this is done the depending package will be left
unconfigured (since attempts to configure it will give errors) and will
not function properly. If it is necessary, a Pre-Depends field can be
used, which has a partial effect even when a package is being unpacked,
as explained in detail below. (The other three dependency fields,
Recommends, Suggests and Enhances, are only used by the various
front-ends to dpkg such as apt-get, aptitude, and dselect.)

For this reason packages in an installation run are usually all unpacked
first and all configured later; this gives later versions of packages
with dependencies on later versions of other packages the opportunity to
have their dependencies satisfied.

In case of circular dependencies, since installation or removal order
honoring the dependency order can't be established, dependency loops are
broken at some point (based on rules below), and some packages may not
be able to rely on their dependencies being present when being installed
or removed, depending on which side of the break of the circular
dependency loop they happen to be on. If one of the packages in the loop
has no postinst script, then the cycle will be broken at that package,
so as to ensure that all postinst scripts run with the dependencies
properly configured if this is possible. Otherwise the breaking point is
arbitrary.

The Depends field thus allows package maintainers to impose an order in
which packages should be configured.

The meaning of the five dependency fields is as follows:


Depends
        
        This declares an absolute dependency. A package will not be
        configured unless all of the packages listed in its Depends
        field have been correctly configured.
        
        The Depends field should be used if the depended-on package is
        required for the depending package to provide a significant
        amount of functionality.
        
        The Depends field should also be used if the postinst, prerm or
        postrm scripts require the package to be present in order to
        run. Note, however, that the postrm cannot rely on any
        non-essential packages to be present during the purge phase.
        
Recommends
        
        This declares a strong, but not absolute, dependency.
        
        The Recommends field should list packages that would be found
        together with this one in all but unusual installations.
        
Suggests
        
        This is used to declare that one package may be more useful with
        one or more others. Using this field tells the packaging system
        and the user that the listed packages are related to this one
        and can perhaps enhance its usefulness, but that installing this
        one without them is perfectly reasonable.
        
Enhances
        
        This field is similar to Suggests but works in the opposite
        direction. It is used to declare that a package can enhance the
        functionality of another package.
        
Pre-Depends
        
        This field is like Depends, except that it also forces dpkg to
        complete installation of the packages named before even starting
        the installation of the package which declares the
        pre-dependency, as follows:
        
        When a package declaring a pre-dependency is about to be
        unpacked the pre-dependency can be satisfied if the depended-on
        package is either fully configured, or even if the depended-on
        package(s) are only unpacked or half-configured, provided that
        they have been configured correctly at some point in the past
        (and not removed or partially removed since). In this case, both
        the previously-configured and currently unpacked or
        half-configured versions must satisfy any version clause in the
        Pre-Depends field.
        
        When the package declaring a pre-dependency is about to be
        configured, the pre-dependency will be treated as a normal
        Depends, that is, it will be considered satisfied only if the
        depended-on package has been correctly configured.
        
        Pre-Depends should be used sparingly, preferably only by
        packages whose premature upgrade or installation would hamper
        the ability of the system to continue with any upgrade that
        might be in progress.
        
        Pre-Depends are also required if the preinst script depends on
        the named package. It is best to avoid this situation if
        possible.
        

When selecting which level of dependency to use you should consider how
important the depended-on package is to the functionality of the one
declaring the dependency. Some packages are composed of components of
varying degrees of importance. Such a package should list using Depends
the package(s) which are required by the more important components. The
other components' requirements may be mentioned as Suggestions or
Recommendations, as appropriate to the components' relative importance.