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
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 .
> Steve Langasek
 whether it's better depends on your personal point of view
 "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