On Fri, Oct 01, 2004 at 08:31:11AM +0200, Petter Reinholdtsen wrote: > Can anyone explain to me why the use of recommends: grub is a policy > violation? I scanned through the policy and failed to find anything > obvious.
If you can't fulfill a Recommends, that's a violation of section 2.2.1. of your policy. >... > [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. There are two possible solutions: - make debian-edu Architecture: any and handle dthe dependencies architecture dependent - Depends: grub | not+i386 cu Adrian -- "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