Your message dated Sat, 10 Jan 2009 11:46:10 +0200
with message-id <[email protected]>
and subject line Re: Bug#61348: Suggestions for other package 
priorities/control fields
has caused the Debian Bug report #61348,
regarding Suggestions for other package priorities/control fields
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
61348: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=61348
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.6.11
Severity: wishlist

Greetings,

I've been thinking about a few enhancements to the package priorities and 
control fields that
would be useful.

- Priority: Obsolete. Packages with this priority would require administrative 
confirmation
and it is stressed that these packages are obsolete. For 'miscutils', 'netstd', 
etc.

- Control field: Documentation. Most packages have documentation packages 
associated with
them, but the association is typically through a Suggests: field. A 
Documentation: field would
be like a Suggests: field, but, in addition, the documentation packages would 
automatically
suggest the package to which they belong. (sort of like the proposed reverse 
Suggests:, or
"Enhances:" field I heard about earlier.)

For instance, libpam0g would declare libpam-doc as a documentation package, so 
whenever an
administrator selects libpam0g in dselect, it would automatically point the 
admin to
libpam-doc the way it points to suggested packages. If the administrator 
selects the
libpam-doc package, dselect behaves as though it Suggests: libpam0g, even 
though there's
no mention of libpam0g in libpam-doc's control info.

Regards,

Alex.

-- System Information
Debian Release: woody
Architecture: i386
Kernel: Linux cornerstone 2.2.14 #1 Wed Feb 23 03:03:04 PST 2000 i686

Versions of packages dpkg depends on:
ii  libc6                         2.1.3-7    GNU C Library: Shared libraries an
ii  libncurses5                   5.0-6      Shared libraries for terminal hand
ii  libstdc++2.10                 1:2.95.2-7 The GNU stdc++ library            


--- End Message ---
--- Begin Message ---
Hi!

On Wed, 2000-03-29 at 14:08:04 -0800, Alexander Hvostov wrote:
> Package: dpkg
> Version: 1.6.11
> Severity: wishlist

> I've been thinking about a few enhancements to the package priorities and 
> control fields that
> would be useful.
> 
> - Priority: Obsolete. Packages with this priority would require 
> administrative confirmation
> and it is stressed that these packages are obsolete. For 'miscutils', 
> 'netstd', etc.

Requiring confirmation would be pretty annoying. For the marking this
has been now solved with debtags (special::obsolete and role::dummy).

> - Control field: Documentation. Most packages have documentation packages 
> associated with
> them, but the association is typically through a Suggests: field. A 
> Documentation: field would
> be like a Suggests: field, but, in addition, the documentation packages would 
> automatically
> suggest the package to which they belong. (sort of like the proposed reverse 
> Suggests:, or
> "Enhances:" field I heard about earlier.)
> 
> For instance, libpam0g would declare libpam-doc as a documentation package, 
> so whenever an
> administrator selects libpam0g in dselect, it would automatically point the 
> admin to
> libpam-doc the way it points to suggested packages. If the administrator 
> selects the
> libpam-doc package, dselect behaves as though it Suggests: libpam0g, even 
> though there's
> no mention of libpam0g in libpam-doc's control info.

I think Suggests (in unidirectional or bidirectional relationships) +
debtags (role::documentation) accomplish this job adequately. Also
I don't think adding this kind of special purpose field is a good
idea, that would only lead to start adding other fields, like for
debugging symbols and similar.

Thus closing.

regards,
guillem


--- End Message ---

Reply via email to