Re: Bug#196367: debian-policy: clarify what to do about priority mismatches
On Sun, 8 Jun 2003 11:55:07 +0100, Colin Watson <cjwatson@debian.org> said:
> On Sat, Jun 07, 2003 at 09:59:18PM -0500, Manoj Srivastava wrote:
>> So fix the bug in the package, and clone it and assign the clone to
>> ftp.
>>
>> It is a bug if the package has the wrong priority, and it is a bug
>> if the override file needs fixing. Just because there are two
>> locations where the fix needs to go in does not invalidate the bug.
> What real benefit (substantial enough to merit a release-critical
> bug) accrues from fixing the informational Priority: field in the
> package?
The whole rationale of having standard/optional/extra was to
allow a tiered install: I could create a CD with standard packages,
and know that I could install Debian from the CD. The subset of
packages would be self sufficient.
If we really cleaned up the optional/extra splits, we could
advance the (admittedly minor) goal of being able to install all
optional packages simultaneously [not that I realistically expect to
achieve that].
> The bug in the package should *not* be serious. That is my chief
> point.
That depends on how important do you think that having self
contained, and consistent, priority levels for packages is. 256
packages out of 10000 is a small anomaly, and one I think we can, and
should fix before release.
We have heard from the ftp master that they would like to have
the maintainers input before affecting changes (indeed, the decision
to lower the dependency level or change the priority needs be taken
at the maintainer level).
So, ideally, the bug is reported against the package, the
maintainer makes a decision, changes the package, and requests the
ftpmasters to make the change in the overrides file, perhaps
explaining why the change was made.
This would make the job of the ftpmaster much easier -- rather
than being told to make decisions for 256 packages, many of which
they may not be familiar with.
>> In other words, I would object to this change, since this would
>> relax rules that allow me to just install base or standard packages
>> from a CD, without needing extraneous packages, with very little
>> benefit to anyone that I can see.
> I'm not suggesting that the rule be relaxed. I'm suggesting that we
> stop applying it in an ineffective place.
I contend this isnot an inappropriate place. The primary
location of the priority is in the package, it is *OVERRIDDEN* in a
central location. Look abovbe to see why I think so.
The change needs to happen in both places, so it is
appropriate to consider it a bug in tha package.
> Since the creation of the override file, the only role I can see for
> the Priority: field in a package's control file is to provide an
> initial suggestion to the ftpmasters as to the priority that should
> be set for that package. We've never considered mismatches between
> packages and the override file to be a serious bug.
I think we may have not dismissed them either: the
installation scripts send me messages whenever I upload a package
with such a mismatch; clearly the expectation is that I fix the
control file. I think we need to have
> Arranging for all overrides to be consistent is a task that needs to
> be done before release, but one which can be done centrally, just
> like the process of deciding which packages should go on which
> CDs.
Wrong again. You can't make decisions about package
relationships and priorities while leaving the maintainer out of the
loop.
> We don't require all packages to carry an up-to-date control field
> saying which CD they should be on!
Strawman, and a red herring. Package relationships,
dependencies, conflicts, and priority requirte knowledge of the
package, and which cd it goes on can then be based on the
relationships.
> Fixing priorities may occasionally require input from maintainers,
> but I do not believe that this is the norm, any more than deciding
> position on CDs routinely requires input from maintainers.
I beg to differ. And this is more than merely fixing
priorities: this may involve making changes to reduce the strength of
a dependency.
manoj
--
The idle mind knows not what it is it wants. Quintus Ennius
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: