[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#273734: education-common: con't fulfill the Recommends on !i386

On Fri, Oct 01, 2004 at 10:31:06AM +0200, Petter Reinholdtsen wrote:

> [http://www.debian.org/doc/debian-policy/ch-archive.html#s-main]
> > 2.2.1 The main section

> > Every package in main and non-US/main must comply with the DFSG
> > (Debian Free Software Guidelines).

> > In addition, the packages in main

> > - must not require a package outside of main for compilation or
> >   execution (thus, the package must not declare a "Depends",
> >   "Recommends", or "Build-Depends" relationship on a non-main
> >   package),
> > - must not be so buggy that we refuse to support them, and
> > - must meet all policy requirements presented in this manual.

> Both grub and dmidecode are in main, so in my view it should be OK to
> recommend both of them.  The fact that they are missing on some archs
> does not make it a policy violation to recommend them.

As Martin has mentioned, recommending non-existent packages has been
known to make certain package management tools unhappy in the past.
This, combined with the fact that both dselect and aptitude pull in
Recommends by default, are clear reasons why we shouldn't want non-main
packages referenced as Recommends.  But for packages that simply don't
exist, only the first issue applies.

It's clear that it would be an RC bug for an arch: powerpc package to
depend on an arch: i386 package, because this would make the package
uninstallable.  Is it an RC bug to recommend that arch: i386 package,
instead of depending on it?  The package would be installable, but not
without some objections from dselect.

If the stricter reading of policy is correct, then the purpose is to
ensure a closure wrt Depends and Recommends in main, not just to avoid
contamination by non-free.  If this is the case, I don't think it would
be appropriate for us to ignore the bug; but I also wouldn't object if
someone else (e.g., the tech ctte or the policy editors) were to clarify
that this is not policy's intention and downgrade the bug.

On Fri, Oct 01, 2004 at 08:31:11AM +0200, Petter Reinholdtsen wrote:

> [Steve Langasek] wrote:
> > Quite agreed.  If there were a clearer reason for having such a
> > recommends, I'm not sure it would be RC (but I'd have to see such a
> > case to know for sure); here, it seems the relationship should
> > definitely be dropped.

> We could drop it as grub is no installed by default by
> debian-installer (earlier lilo was the default), but this is just one
> example of a package of a package missing on some archs, and which we
> want to include in debian-edu if it exist.  We want to pull such
> packages in if they exist on the arcitecture, and keep running without
> the packages if they are missing.  I believed recommend was a OK and
> policy compliant way to do this, so I would really like to hear the
> justifications for claiming this breaks with policy.

> One other example is dmidecode, present on some archs, and missing on
> others.  We want to document the relationship, but can't make it as
> strong as 'depend' as we want the task package to be installable also
> om archs without DMI.

At first, I thought this meant that the package was a Recommends:
instead of a Depends: only because of its limited architecture
availability.  I think this would be a bad workaround; if the reality is
that the metadata (the principal contents of the package in question)
varies between architectures, this would mean the package should be
arch: any instead of arch: all.

However, I see that education-common has all of its package
relationships listed in Recommends: and Suggests: instead of in
Depends:.  I gather that this is to make the package more likely to be
eligible for testing, as you mentioned.  I'm not sure this is a good
idea; if the testing scripts looked at Recommends: as well as Depends:
(which, though hairy, is in many ways a better idea than the current
after-the-fact bug filing if we're going to consider Recommends: RC),
and using Recommends: gave you no advantage where britney is concerned,
where would these packages be listed?  If the answer would be
'Depends:', then I think the current state is also a bad kludge from
that standpoint; but either way, it makes it harder to know which is the
right way to handle dmidecode.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: