On Sun, Oct 03, 2004 at 02:53:57PM -0400, Joey Hess wrote: > (Why are different parts of this thread cc'd to -devel and -release and > the bug at seeming random?) This discussion belongs on -devel, not -release. > > 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. > We would still list everything in recommends. There were many reasons why I > moved all contents of these tasks to the recommends field, including: > - Getting the packages into testing, which was previously apparently > impossible. > - Avoiding the common problem with task packages that if you remove > one package in the task, you have to remove the task package as > well, since its dependecies are then broken. > - As part of the phasing out of the old reason for the old-type task > packages; selection of the packages in these tasks are not handled at > the tasksel level by recommends fields ayway, but by tasksel package > lists in the education-tasks package. The new task packages will > mostly be useful for post-install sysadmin and upgrade purposes. The first two of these advantages would no longer be present if britney treated Recommends the same way as it treats Depends, which is why I ask. I'm confused about your third point, here; the current debian-edu package represents the "new"-style task packages? What is clear to me is that the intended semantics of the education-common are that it install the Recommends: if available, and ignore them if they're not. Since your tests show that this is consistent with the handling of Recommends by the various front-ends, regardless of policy's phrasing, I'm content to ignore such per-arch Recommends for sarge. I think the grub recommendation should still be dropped; since this is now the default boot loader, I think pulling in a second bootloader when the default has been overridden is likely to do more harm than good. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature