(Why are different parts of this thread cc'd to -devel and -release and
the bug at seeming random?)
Steve Langasek wrote:
> 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.
I tested by making sleepd recommend no-such-package in my personal apt
repository. In aptitude, if I select sleepd for install, it installs
fine, although if I open the details pane for sleepd I do see a red line:
--\ Recommends
--- apmd
--- no-such-package (UNAVAILABLE)
In dselect, there was no mention of no-such-package, and it seemed willing
to install sleepd despite the missing recommendation, with no complaints.
apt-get install sleepd notes that no-such-package is recommended, but
only as information the same as it would for any recommends missing or not.
I did not test synaptic.
> 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.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature