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

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

> 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

> 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.

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: