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

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

On Fri, Oct 01, 2004 at 08:10:41PM -0700, Steve Langasek wrote:
> 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.

A package in non-free is definitely not worse than no package at
all [1].

The only reasonable purpose of this part of policy seems to be to 
enforce that all Depends and Recommends are fulfillable inside main.

Someone might have a different reading of the text of your policy than I 
have, but independent of the policy text it simply doesn't make any 
sense that removing a package from non-free would make a Recommends of 
it correct [2].

> Steve Langasek


[1] whether it's better depends on your personal point of view
[2] "correct" in the sense of "no longer RC"


       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply to: