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.
[Martin Schulze] > I'd rather investigate why education-common needs to recommend grub > at all. > > The name makes me think that it's a "task" package, basically consisting > on dependencies. Does it need to have a dependency to grub at all? Yes, education-common is a task package. It recommends grub to document that we prefer grub over lilo. It was previously a depend, but this made it impossible to get the package into testing, so we downgraded it. [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.
