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
cu
Adrian
[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: