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