On Mon, Nov 29, 1999 at 06:30:43PM -0500, Raul Miller wrote:
> On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote:
> > > need anything that's not free at all". If we put weaken Suggest or
> > > create a new weaker version of it we don't do that since we still
> > > tell people that th
On Mon, Nov 29, 1999 at 08:54:56PM +0100, Roland Rosenfeld wrote:
> Your proposal means, that I should remove netpbm-nonfree from
> transfig's suggests and add "Enhances: netpbm-nonfree" to
> netpbm-nonfree.
>
> Is this really the correct way? Why does the maintainer of
> netpbm-nonfree have to
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote:
> > need anything that's not free at all". If we put weaken Suggest or
> > create a new weaker version of it we don't do that since we still
> > tell people that there are non-free packages that can improve things.
On Mon, Nov 29, 1
On Mon, 29 Nov 1999, Wichert Akkerman wrote:
> Enhances works in the opposite direction from Suggests: it allows a
> package a to state that it can enhance the functionality of a
> package b. So instead of package b declaring a Suggests on package
> a we now make package a Enhance package b.
Are
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote:
> need anything that's not free at all". If we put weaken Suggest or
> create a new weaker version of it we don't do that since we still
> tell people that there are non-free packages that can improve things.
But sadly, on occasion,
Previously Joseph Carter wrote:
> My first condition is that this is phased in--it must not be a requirement
> for potato or even potato+1. (I'll accept potato alone if a reasonable
> consensus of people believe we can do it for potato+1 without interfering
> with release timeframes..)
I'm lookin
Previously Chris Waters wrote:
> The problem with the "Enhances" idea (which several people, including
> me, mentioned at the time) is that it puts the responsibility on the
> wrong package.
Yes and no. It's actually a nice addition to the current sent of
relations since we had no way for this kin
Previously Raul Miller wrote:
> As I recall, the discussion kind of died out when people realized that
> this would require a dpkg change -- at the time, "dpkg change" seemed
> to imply that several years might go by before the feature became
> available.
Well, the times they are a'changing. Part
Previously Raul Miller wrote:
> I agree that we shouldn't require it for potato.
However if the amount of work is reasonably small I wouldn't mind
personally submiting patches for packages or NMU'ing a couple if needed.
If this is done it means the FSF might start distributing Debian as
well, whic
> On Sun, Nov 28, 1999 at 12:01:44AM -0700, Bdale Garbee wrote:
> > There needs to be a canonical list of the packages that are part of the
> > build-essential set *somewhere*.
>
> Why?
Ok, I've gone back and re-read the policy section carefully, and thought about
this quite a bit. Fundamental
On Sun, Nov 28, 1999 at 07:16:19PM +0100, Goswin Brederlow wrote:
> [EMAIL PROTECTED] (Brian Mays) writes:
>
> > > Policy says that any binary must come with a manpage. I would like to
> > > have the same for packages.
> >
> > For every package? You must be kidding!!
> >
> > > I just looked for
On Sun, Nov 28, 1999 at 10:14:29PM -0800, Joseph Carter wrote:
> I will conditionally support this...
>
> My first condition is that this is phased in--it must not be a requirement
> for potato or even potato+1. (I'll accept potato alone if a reasonable
> consensus of people believe we can do it
Thank you for the additional information you have supplied regarding
this problem report. It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.
Your message has been sent to the package maintainer(s):
Debian Policy List
If you wish to co
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> > I assume we are all aware of the discussion a couple of months ago
> > about removing references to non-free from main. There was a consensus
> > this should be done and a consensus was formed to do this via a new
> > Enhances relation for packages.
I (Brian Mays) wrote:
> > While I agree that it is probably a good idea for large packages, with
> > many binaries, to provide such a man page (in section 7, of course), it
> > makes no sense for packages in general. Personally, I think that such
> > policy would be a waste of our developers' tim
On Sun, Nov 28, 1999 at 12:01:44AM -0700, Bdale Garbee wrote:
> There needs to be a canonical list of the packages that are part of the
> build-essential set *somewhere*.
Why?
The point of the current way is to reduce the risk of having an outdated
authoritative list of build-essential packages
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> I assume we are all aware of the discussion a couple of months ago
> about removing references to non-free from main. There was a consensus
> this should be done and a consensus was formed to do this via a new
> Enhances relation for packages.
That's
[EMAIL PROTECTED] (Brian Mays) writes:
> > Policy says that any binary must come with a manpage. I would like to
> > have the same for packages.
>
> For every package? You must be kidding!!
>
> > I just looked for a parser generator that outputs C++ code and found
> > pccts. After installation
> this avoids the need to choose between debconf and hand-edited
> configuration (which is not a solution at all) - the sysadmin can modify
> the template however they like and their changes will remain after the
> next time the real config file is generated...and values will still be
> pulled out
Your message dated Mon, 29 Nov 1999 00:38:58 +
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy/packaging-manual 3.1.1.1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
Your message dated Mon, 29 Nov 1999 00:38:58 +
with message-id <[EMAIL PROTECTED]>
and subject line Closed in debian-policy/packaging-manual 3.1.1.1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case
Package: packaging-manual
The current packaging-manual dictates how dselect reacts to relations
from packages. If you look at section 8.2 there are statements
such as:
`Recommends'
[...]
It is treated by `dselect' exactly as `Depends' is; this makes it
hard for
On Mon, Nov 29, 1999 at 12:39:46AM +0100, Wichert Akkerman wrote:
> I assume we are all aware of the discussion a couple of months ago
> about removing references to non-free from main. There was a consensus
> this should be done and a consensus was formed to do this via a new
> Enhances relation f
Package: debian-policy
I assume we are all aware of the discussion a couple of months ago
about removing references to non-free from main. There was a consensus
this should be done and a consensus was formed to do this via a new
Enhances relation for packages.
Enhances works in the opposite direc
24 matches
Mail list logo
