(debian)
To: [EMAIL PROTECTED]
cc: debian-policy@lists.debian.org
Subject: Re: [PROPOSED] Change package relations policy to remove references
to non-free from main
In-Reply-To: Message from Joseph Carter <[EMAIL PROTECTED]>
of "Tue, 30 Nov 1999 22:44:49 PST." <[EMAIL P
On Fri, Dec 03, 1999 at 01:33:43PM -0800, Joseph Carter wrote:
> On Wed, Dec 01, 1999 at 02:57:49PM -0700, Jason Gunthorpe wrote:
> > > Perhaps the keyring (entire keyring) should be in non-us rather than
> > > contrib?
> > Why? There is nothing export-controlled about the keyring, if the keyring
>
On Fri, 3 Dec 1999, Joseph Carter wrote:
> > Why? There is nothing export-controlled about the keyring, if the keyring
> > should go anyplace, it would be data/main or just plain main.
> The keyring doesn't serve much purpose without gnupg in non-US/main.
> Since this creates a dependency of so
On Wed, Dec 01, 1999 at 02:57:49PM -0700, Jason Gunthorpe wrote:
> > Perhaps the keyring (entire keyring) should be in non-us rather than
> > contrib?
>
> Why? There is nothing export-controlled about the keyring, if the keyring
> should go anyplace, it would be data/main or just plain main.
The
On Fri, Dec 03, 1999 at 11:03:19AM -0600, Manoj Srivastava wrote:
> Free and non-free are a consequence of the *licence*, which
> has little to do with how the package works technically.
Not according to policy. Else gimp-nonfree wouldn't be non-free, the code
contained therein is comple
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
>> Free and non-free are a consequence of the *licence*, which
>> has little to do with how the package works technically.
Raul> Sure, and now you seem to be advocating some new package headers
Raul> which are a consequence of the licens
On Sat, Dec 04, 1999 at 01:31:50AM +1000, Anthony Towns wrote: [in response
to Raul]
> > Once again: why are we talking about making our package meta-data
> > specification more complicated to support a small subset of non-free
> > packages?
> Eh? The only `specification' change that I'd even vague
> Raul> I just don't think that specifically enhancing the package structure
> Raul> with extra kludge to specially support non-free packages is the right
> Raul> way to go.
>
> Look below to see why it is not a kludge.
>
> Raul> I think that the right way to go is to put the referenc
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> I just don't think that specifically enhancing the package structure
Raul> with extra kludge to specially support non-free packages is the right
Raul> way to go.
Look below to see why it is not a kludge.
Raul> I think that
> On Fri, Dec 03, 1999 at 03:47:16PM +1000, Anthony Towns wrote:
> > Suppose we were to have four distributions, instead of three: non-free,
> > contrib, main and gpl-only. gpl-only being that subset of main which is
> > gpl-compatible.
> If we create a gpl-compatible, it will be for developers mor
> On Thu, Dec 02, 1999 at 11:10:56AM -0500, Raul Miller wrote:
> > On Thu, Dec 02, 1999 at 07:20:39PM +1000, Anthony Towns wrote:
> > > I don't think that's any worse than having a GPL-compatible package
> > > reference a non-GPL-compatible package, if we were to have a gpl-only
> > > distribution.
On Thu, Dec 02, 1999 at 11:10:56AM -0500, Raul Miller wrote:
> On Thu, Dec 02, 1999 at 07:20:39PM +1000, Anthony Towns wrote:
> > I don't think that's any worse than having a GPL-compatible package
> > reference a non-GPL-compatible package, if we were to have a gpl-only
> > distribution.
> Huh?
>
Raul Miller <[EMAIL PROTECTED]> writes:
> On Fri, Dec 03, 1999 at 02:49:24PM -0800, Chris Waters wrote:
> > The fact that I have already moved any non-free suggests in my
> > packages to the package description (even though I didn't have to)
> > should demonstrate that I am quite conversant with t
> Raul> This isn't about "talking about other packages".
On Thu, Dec 02, 1999 at 01:51:53PM -0600, Manoj Srivastava wrote:
> Then it should be. Your raison de etre seems to be that good
> users shall find references to non-free software r5epugnant, and
> hence one must purge all referen
On Fri, Dec 03, 1999 at 02:49:24PM -0800, Chris Waters wrote:
> The fact that I have already moved any non-free suggests in my
> packages to the package description (even though I didn't have to)
> should demonstrate that I am quite conversant with the difference.
> However, what Manoj, Knghtbrd, I
Raul Miller <[EMAIL PROTECTED]> writes:
> On Fri, Dec 03, 1999 at 12:19:57AM -0800, Chris Waters wrote:
> > Chris Waters <[EMAIL PROTECTED]> writes:
> > > The other objection I've seen is, basically, "the purity of the system
> > > is marred by the very presence of even the *names* of non-free
> >
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> non-us/main is very different from non-free. The first consists of
Raul> DFSG software with temporary and/or localized distribution problems.
Raul> The second consists of non-DFSG software.
Yes, I am aware of the obvious differ
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> What about that perl one liner? Or just plain old dpkg -s? Or vi
Raul> /var/lib/dpkg/status? Or, apt-cache dumpavail? Or future simple
programs
Raul> of various sorts?
dpkg and apt-cache could be modified to respect any ref
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> And the point is: we are supposed to support non-free packages, we're
Raul> not supposed to make them a part of debian.
A suggests is not making it part of Debian, espescially if the
user interface tools are modified not to
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> This isn't about "talking about other packages".
Then it should be. Your raison de etre seems to be that good
users shall find references to non-free software r5epugnant, and
hence one must purge all references from the pack
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> On Fri, Dec 03, 1999 at 12:19:57AM -0800, Chris Waters wrote:
>> I can't think of anything to add to that. Except to comment that it
>> might be rather difficult to document samba if you could never refer
>> to non-free software. :-
> > Raul Miller <[EMAIL PROTECTED]> writes:
> > > Personally, I think that hard-coding into a DFSG package a reference
> > > to some non-DFSG package is rather grotesque. I'm disappointed that
> > > we disagree on this issue.
On Thu, Dec 02, 1999 at 07:20:39PM +1000, Anthony Towns wrote:
> I don'
> [in one message]
> Raul Miller <[EMAIL PROTECTED]> writes:
>
> > Personally, I think that hard-coding into a DFSG package a reference
> > to some non-DFSG package is rather grotesque. I'm disappointed that
> > we disagree on this issue.
>
> [in another message]
> Chris Waters <[EMAIL PROTECTED
> Raul Miller <[EMAIL PROTECTED]> writes:
> > Personally, I think that hard-coding into a DFSG package a reference
> > to some non-DFSG package is rather grotesque. I'm disappointed that
> > we disagree on this issue.
I don't think that's any worse than having a GPL-compatible package
reference a
[in one message]
Raul Miller <[EMAIL PROTECTED]> writes:
> Personally, I think that hard-coding into a DFSG package a reference
> to some non-DFSG package is rather grotesque. I'm disappointed that
> we disagree on this issue.
[in another message]
Chris Waters <[EMAIL PROTECTED]> writes:
> The
Julian Gilbey <[EMAIL PROTECTED]> writes:
> That is why we have a Bug Tracking System: these are bugs and should
> be dealt with through the BTS. Making policy changes to solve these
> problems is pointless: they will still need to be reported as bugs.
Quite right, perhaps I shouldn't have inter
> So let us just pretend that we just implement one of
> weak-suggests and reverse-suggests and call it Enhances, shall we? ;-)
I think there appears to be enough of a reason to allow both of these:
they both have their strengths and weaknesses, but both are useful in
some contexts:
weak
> People declare inappropriate Suggests all the time; anything we can do
> to reduce that would be a help. Suggests should have documentation
> attached explaining *why* the suggestion is made. Someone suggests
> "netscape", and that really loses when they should suggest
> "www-browser"; but then
> > > If the references are never displayed *to people who dio not
> > > want* tham, why is that so bad? And why are we going through hoops to
> > > impose the religion on everyone else as well?
Raul Miller wrote:
> > What do you mean by "display"? You want to chain people to dselect?
Raul Miller wrote:
> > If the references are never displayed *to people who dio not
> > want* tham, why is that so bad? And why are we going through hoops to
> > impose the religion on everyone else as well?
>
> What do you mean by "display"? You want to chain people to dselect?
Dselec
On Tue, Nov 30, 1999 at 11:34:45PM -0600, Manoj Srivastava wrote:
> That happens to be your interpretation of the social contract.
> I see the packages in main to be absolutely free (fulfilling the
> social contract about 100% free distribution) while retaining
> the freedom to talk abou
On Wed, 1 Dec 1999, Raul Miller wrote:
> > Perhaps the keyring (entire keyring) should be in non-us rather than
> > contrib?
On Wed, Dec 01, 1999 at 02:57:49PM -0700, Jason Gunthorpe wrote:
> Why? There is nothing export-controlled about the keyring, if the keyring
> should go anyplace, it would b
On Wed, 1 Dec 1999, Raul Miller wrote:
> Perhaps the keyring (entire keyring) should be in non-us rather than
> contrib?
Why? There is nothing export-controlled about the keyring, if the keyring
should go anyplace, it would be data/main or just plain main.
Jason
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> We should be giving users more choice. Not less.
The problem is that lack of time or sheer laziness intrudes. We
should do what we can to help people who want free software systems.
There are other things we can do, but they should take seco
> Raul> For the worst case "suggests -> enhances" mess, you could
> Raul> even create a single empty non-free package which enhances
> Raul> the free part and which suggests any of a suite of non-free
> Raul> software. This puts administrative control in the right place,
> Raul> yet leaves a c
>Consider, all ther perl libraries could 'enhance' perl, so it would be
>possible to generate a list of all the perl libraries. All C -dev packages
>could enhance gcc, python libraries python, etc, etc.
As a software developer and user of Debian (but not currently a Debian
developer) I've been thi
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Joey Hess <[EMAIL PROTECTED]> writes:
>> Chris Waters wrote:
>> > I have been unable to think of any actual legitimate use of enhances,
>> > and you don't seem to be doing much better.
>> Here, I've thought of one. Nextaw coul
Hi,
>>"Anthony" == Anthony Towns writes:
Anthony> FWIW, I vaguely do too: enhances doesn't scale particularly
Anthony> well,
Actually, niether does suggests, if we are trying to be
exhaustive. ZI can come up with thousands of packages that depend on
and enhance Emacs; having all thes
Hi,
>>"Thomas" == Thomas Bushnell, BSG <[EMAIL PROTECTED]> writes:
Thomas> I like the change to the policy document in question.
And I do not. Technically speaking, tihs additions is is a
bogosity, it adds packages, thast serve no purpose other than
religious, adds yet another layer of
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Wichert Akkerman <[EMAIL PROTECTED]> writes:
>> 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
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> We need to have a clean administrative interface between the free and
Raul> the non-free parts of debian.
I think I agree here.
Raul> Not everyone is going to be able to use the non-free parts, and
Raul> not all distributi
On Tue, Nov 30, 1999 at 01:36:14PM -0800, Joey Hess wrote:
> Tomasz Wegrzanowski wrote:
> > consider package that has no dep, rec nor sug field.
> > now it was possible to simply select and install it
> > but with ench field the whole database has to be scaned
> > one more time for each package
>
On Wed, Dec 01, 1999 at 07:07:59AM -0500, Raul Miller wrote:
> Perhaps the keyring (entire keyring) should be in non-us rather than
> contrib?
Now how many months have I been saying that? =p =>
--
- Joseph Carter GnuPG public key: 1024D/DCF9DAB3, 2048g/3F9C2A43
- [EMAIL PROTECTED]
On Wed, Dec 01, 1999 at 10:28:23AM +, Oliver Elphick wrote:
> >I think the keyring belongs in non-US/main, but it can't get there until
> >20 September 2000 unless we change our policy to not consider US patents
> >as making something automatically non-free.
>
> I did not realise that wa
On Wed, 1 Dec 1999, Julian Gilbey wrote:
> > P.S. Should the debian-keyring package now be split, with the gpg
> > keyring placed in main, and the pgp keyring in contrib?
On Tue, Nov 30, 1999 at 08:08:41PM -0700, Jason Gunthorpe wrote:
> Most certainly not - GPG is perfectly capable of handling th
On Tue, Nov 30, 1999 at 10:02:28PM -0500, Raul Miller wrote:
> On Wed, Dec 01, 1999 at 02:03:48AM +, Julian Gilbey wrote:
> > I would encourage people to reread sections 4 and 5 of the social
> > contract. Debian *acknowledges* the existence of non-free software,
> > and "We acknowledge that s
On Tue, Nov 30, 1999 at 10:11:28PM -0500, Thomas Bushnell, BSG wrote:
> Julian Gilbey <[EMAIL PROTECTED]> writes:
>
> > I would encourage people to reread sections 4 and 5 of the social
> > contract. Debian *acknowledges* the existence of non-free software,
> > and "We acknowledge that some of ou
Joey Hess <[EMAIL PROTECTED]> writes:
> Chris Waters wrote:
> > I have been unable to think of any actual legitimate use of enhances,
> > and you don't seem to be doing much better.
> Here, I've thought of one. Nextaw could be said to enhance xcontrib,
> because xfontsel in that package is rather
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote:
> It's true that for some of the existing relations replacing Suggests
> with Recommends puts the responsibility on the wrong package. However
s/Recommends/Enhances/ I take it?
> a reverse relation is the only way to completely rem
On Tue, Nov 30, 1999 at 05:52:17PM -0500, Raul Miller wrote:
> And we still don't have a good example case where "free package suggests
> non-free package" is better than "non-free package enhances free package"
Mozilla.
Suggests: ... xanim | ucbmpeg-play ...
Why the hell would xanim or ucbmpeg
On Tue, Nov 30, 1999 at 09:01:18PM +0100, Wichert Akkerman wrote:
> > > I think what you're saying here is: the policy which supports Enhances:
> > > should be the same as the policy which supports Keywords:
> > >
> > > ?
> >
> > Yes.
>
> Euh, why? They are completely unrelated. *completely*.
b
Package: debian-policy
Version: 3.1.1.0
Severity: normal
Joseph Carter wrote:
>I think the keyring belongs in non-US/main, but it can't get there until
>20 September 2000 unless we change our policy to not consider US patents
>as making something automatically non-free.
I did not realise th
On Tue, Nov 30, 1999 at 01:34:25PM -0800, Joey Hess wrote:
> Well, a simple[1] perl command can tell us exactly what packages are affected:
>
> [EMAIL PROTECTED]:~>perl -ne '($a,$b)=m/^(.*?):\s+(.*)/;$fields{lc $a}=$b; if
> ($a
> eq "" || eof) { if ($fields{section}=~/(contrib|non-free)/) {
> $no
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> (a) The package should recommend a virtual package which has a free
instance.
Raul> (b) The package should be in contrib.
Raul> (c) The reverse link should be represented using enhances.
Raul> Yeah, I recognize that (a) involves r
Chris Waters wrote:
> I have been unable to think of any actual legitimate use of enhances,
> and you don't seem to be doing much better.
Here, I've thought of one. Nextaw could be said to enhance xcontrib, because
xfontsel in that package is rather useless without it (if you want to pick
the 200
Julian Gilbey wrote:
> Which available file? /var/lib/dpkg/available or
> /var/cache/apt/available? apt-get only updates the former if it is
> being called from dselect.
I always update from dselect, just because I really dislike that behavior of
apt. I'm still puzzled what's going on on my syst
On 1 Dec 1999, Chris Waters wrote:
> Actually, EUDC depends on emacs. I don't think emacs should suggest
> EUDC (which is what "EUDC enhances emacs" would mean).
I think for Enhances to be (long term) usefull it should not mean the same
as suggests - Enhancing packages should not automatically
Julian Gilbey <[EMAIL PROTECTED]> writes:
> I would encourage people to reread sections 4 and 5 of the social
> contract. Debian *acknowledges* the existence of non-free software,
> and "We acknowledge that some of our users require the use of programs
> that don't conform to the Debian Free Soft
On Wed, 1 Dec 1999, Julian Gilbey wrote:
> P.S. Should the debian-keyring package now be split, with the gpg
> keyring placed in main, and the pgp keyring in contrib?
Most certainly not - GPG is perfectly capable of handling the content of
both rings. The only little problem is that some people
On Wed, Dec 01, 1999 at 02:03:48AM +, Julian Gilbey wrote:
> I would encourage people to reread sections 4 and 5 of the social
> contract. Debian *acknowledges* the existence of non-free software,
> and "We acknowledge that some of our users require the use of programs
> that don't conform to
On Wed, Dec 01, 1999 at 04:15:22PM -0800, Chris Waters wrote:
> Hmm, ok. I'm not convinced that there'll ever be any real[*] need to
> do so, but I agree that adding the capability does no harm.
>
> [*] that is to say, technical, rather than political.
Actually, if you look at what's supported i
On Tue, Nov 30, 1999 at 05:20:37PM -0600, Manoj Srivastava wrote:
> No. But I am voicing my objection to a method that requires
> serendipitous free equivalantrs of all non-free packages to
> serve as a workaround.
That's just one of several options.
We need to have a clean administrat
> > And, it looks like task-chinese-t should be in contrib.
On Tue, Nov 30, 1999 at 03:25:34PM -0800, Joey Hess wrote:
> I dunno, it depends on all free stuff.
It contains no free software, just the obligatory /usr/doc/ entries,
and it suggests numerous non-free packages.
Then again, maybe it sh
On Tue, Nov 30, 1999 at 01:19:04PM -0600, Manoj Srivastava wrote:
> [...]
> As it stands, I agree to the enhanced proposal, but would
> object strongly to using enhances to remove mention of non-free
> packages from main (we should do it in dselect, dpkg, and apt; with
> the pacjkages no
> Since when has political corectness and quick hacks been
> favoured over doing things teh right way? The correct thing is not to
> coerce the relationship into what it is not because we have been
> cowed by the FSF.
I would encourage people to reread sections 4 and 5 of the social
con
On Tue, Nov 30, 1999 at 03:25:34PM -0800, Joey Hess wrote:
> Raul Miller wrote:
> > Hmm... ssh should no longer be non-free, if I recall correctly.
>
> Yeah, I agree. For some reason my available file has this, though:
>
> Package: ssh
> Priority: optional
> Section: non-US/non-free
>
> I have n
On Tue, Nov 30, 1999 at 01:34:25PM -0800, Joey Hess wrote:
> Joseph Carter wrote:
> > I'm not so sure it's such a small set of packages, but I'm agreeable to
> > that if we can do it.
>
> Well, a simple[1] perl command can tell us exactly what packages are affected:
> [...]
> So 104 suggests scatt
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> I do notthink it correct for emacs to suggest EUDC, but it is
> quite appropriate for EUDC to say it enhances emacs.
Actually, EUDC depends on emacs. I don't think emacs should suggest
EUDC (which is what "EUDC enhances emacs" would mean).
At 17:20 -0600 1999-11-30, Manoj Srivastava wrote:
> Raul> And we still don't have a good example case where "free package
>suggests
> Raul> non-free package" is better than "non-free package enhances free
>package"
>
>Latex2html suggesting non-fee bits which can create gifs. ZIf
> it can c
On Wed, Dec 01, 1999 at 04:30:19PM -0800, Chris Waters wrote:
> A Weak-Suggests could be every bit as invisible as my current solution
> -- maybe even more so -- for those who don't want non-main software,
> but would have big advantages for those who *do* use non-main
> software.
>
> Enhances is
On Tue, Nov 30, 1999 at 02:24:58PM -0700, Jason Gunthorpe wrote:
> On 30 Nov 1999, Manoj Srivastava wrote:
> > As it stands, I agree to the enhanced proposal, but would
> > object strongly to using enhances to remove mention of non-free
> > packages from main (we should do it in dselect,
Wichert Akkerman <[EMAIL PROTECTED]> writes:
> 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 cu
Raul Miller <[EMAIL PROTECTED]> writes:
> On Mon, Nov 29, 1999 at 08:54:56PM +0100, Roland Rosenfeld wrote:
> > Is this really the correct way? Why does the maintainer of
> > netpbm-nonfree have to change his package every time some package from
> > main suggests it? This may be political corre
Previously Tomasz Wegrzanowski wrote:
> btw: this make dpkg even slower than it is now
And where do you base that on? I can assure you that is not true. The
only things it slows down a bit is dselect since it needs to scan some
packages when you select a package. If that slowdown is too big it's
a
Previously Joey Hess wrote:
> Dpkg already has to load the whole database. It needs to see if anything
> currently installed conflicts with the package, etc.
Furthermore dpkg doesn't really need to do anything with Enhances and
can safely ignore it. dselect does need some to do some extra work
but
Previously Joseph Carter wrote:
> On Mon, Nov 29, 1999 at 10:54:54AM -0500, Raul Miller wrote:
> > I think what you're saying here is: the policy which supports Enhances:
> > should be the same as the policy which supports Keywords:
> >
> > ?
>
> Yes.
Euh, why? They are completely unrelated. *co
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Raul Miller <[EMAIL PROTECTED]> writes:
Raul> That's solvable: create a virtual package which has a free instance
Raul> (such as Mozilla) which provides the interface you're taking advantage
of.
Raul> Actually, this particular ca
Raul Miller wrote:
> Hmm... ssh should no longer be non-free, if I recall correctly.
Yeah, I agree. For some reason my available file has this, though:
Package: ssh
Priority: optional
Section: non-US/non-free
I have no idea why. Most odd.
> And, it looks like task-chinese-t should be in contrib
> Joseph Carter wrote:
> > I'm not so sure it's such a small set of packages, but I'm agreeable to
> > that if we can do it.
On Tue, Nov 30, 1999 at 01:34:25PM -0800, Joey Hess wrote:
> Well, a simple[1] perl command can tell us exactly what packages are affected:
...
Hmm... ssh should no longer
> >> If, e.g, my package can take advantage of Netscape, then it should
> >> be the responsibility of my package, not Netscape, to mention that
> >> fact. Otherwise, Netscape (in particular) may need to have hundreds
> >> of packages listed under "Enhances". Not to mention that fact that it
>
Tomasz Wegrzanowski wrote:
> consider package that has no dep, rec nor sug field.
> now it was possible to simply select and install it
> but with ench field the whole database has to be scaned
> one more time for each package
Dpkg already has to load the whole database. It needs to see if anythin
Joseph Carter wrote:
> I'm not so sure it's such a small set of packages, but I'm agreeable to
> that if we can do it.
Well, a simple[1] perl command can tell us exactly what packages are affected:
[EMAIL PROTECTED]:~>perl -ne '($a,$b)=m/^(.*?):\s+(.*)/;$fields{lc $a}=$b; if
($a
eq "" || eof) {
On 30 Nov 1999, Manoj Srivastava wrote:
> As it stands, I agree to the enhanced proposal, but would
> object strongly to using enhances to remove mention of non-free
> packages from main (we should do it in dselect, dpkg, and apt; with
> the pacjkages not displaying non-free packages u
On Tue, Nov 30, 1999 at 11:57:53AM -0800, Joey Hess wrote:
> Tomasz Wegrzanowski wrote:
> > btw: this make dpkg even slower than it is now
>
> What do you have to support this statement? I can see ways that Enhances:
> could be implemented internally in dpkg as a form of Suggests, with probably
>
Manoj Srivastava wrote:
> >>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
>
> Wichert> Yes and no. It's actually a nice addition to the current sent of
> Wichert> relations since we had no way for this kind of reverse relation.
>
> I agree.
As do I.
> Wichert>
Tomasz Wegrzanowski wrote:
> btw: this make dpkg even slower than it is now
What do you have to support this statement? I can see ways that Enhances:
could be implemented internally in dpkg as a form of Suggests, with probably
no speed differance.
--
see shy jo
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> Go over to debian-legal and read the Corel threads there, then
Raul> come back and tell me that everyone is happy, in general, about
Raul> debian distributions which mix free and non-free software.
So we should let the peopl
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
Raul> 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 rea
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> `Enhances'
Wichert>This field is similar to Suggests but works in the opposite
Wichert>direction. It is used to declare that a package can enhance
Wichert>the functionality of another package.
Wichert>
Hi,
>>"Wichert" == Wichert Akkerman <[EMAIL PROTECTED]> writes:
Wichert> Yes and no. It's actually a nice addition to the current sent of
Wichert> relations since we had no way for this kind of reverse relation.
I agree.
Wichert> It's true that for some of the existing relations repla
Hi,
>>"Raul" == Raul Miller <[EMAIL PROTECTED]> writes:
>> If, e.g, my package can take advantage of Netscape, then it should
>> be the responsibility of my package, not Netscape, to mention that
>> fact. Otherwise, Netscape (in particular) may need to have hundreds
>> of packages listed under
I second Wichert's proposal that policy recommend
non-free package Enhances: free package, in place of
free package Suggests: non-free package.
--
Raul
On Mon, Nov 29, 1999 at 10:54:54AM -0500, Raul Miller wrote:
> I agree that we shouldn't require it for potato. I agree that non-compliance
> with this policy probably won't be release critical. On the other hand,
> I find it hard to imagine any circumstance that would prevent fixing
> the small
On Mon, Nov 29, 1999 at 10:06:39PM +0100, Wichert Akkerman wrote:
> 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 n
Previously Julian Gilbey wrote:
> Where does non-US fit into this, BTW? Can we suggest stuff in
> non-US/main from stuff in main under this proposal?
Personally I like to consider main and non-US/main together as
`Debian main' (or actually just `Debian'). So I would say it
would still be allowed.
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,
1 - 100 of 109 matches
Mail list logo
