[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#273734: education-common: con't fulfill the Recommends on !i386

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

Reply to: