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
> Why not have a Legal: or License: field that specifies the license(s)
> the package adheres to? This does not impact dpkg/apt in any way (as I
Most of the software in main is under a fairly small set of licenses,
but almost every package in non-free has its own individual reason for being
there
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,
>>"Ronald" == Ronald van Loon <[EMAIL PROTECTED]> writes:
Ronald> Well, the problem sees to be this:
Ronald> person A is installing Debian on his system. However, he has
Ronald> some restrictions as to what packages he can use (for
Ronald> example, because his distribution only has certai
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 Wed, Dec 01, 1999 at 01:45:41PM +0100, Ronald van Loon wrote:
> person A is installing Debian on his system. However, he has some
> restrictions as to what packages he can use (for example, because his
> distribution only has certain packages available (practical example), or
> because his emplo
> `Enhances'
> This field is similar to Suggests but works in the opposite
> direction. It is used to declare that a package can enhance
> the functionality of another package.
Has anyone else noticed that this is in fact a COME FROM command?
IAMFI. HTH,
--
Moray Allan
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 Tue, Nov 30, 1999 at 11:33:41PM -0800, Daniel Quinlan wrote:
> liblockdev seems like a really good idea, which we're considering
> adding to LSB (although the library function names may get changed
> along the way so they all have the same prefix).
lockdev_1.0.0_i386.changes just uploaded with
> s/Recommends/Enhances/ I take it?
>
> > a reverse relation is the only way to completely remove references
> > to non-main packages from main, which is what this proposal is all
> > about. It's not all about design, there is a political message here
> [..]
>
> RMS originally suggested simply no
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
liblockdev seems like a really good idea, which we're considering
adding to LSB (although the library function names may get changed
along the way so they all have the same prefix).
Is there a reason that no Debian packages are using it?
Package: liblockdev0g
Version: 0.11.1
Architecture: i386
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
(I fondly remember my second slackware install. I had found out enough the
first time around to know that the names of commands was key to learning
linux. Several of the core slackware packages listed all the commands in
them in their descriptions, and raced against the install to get the command
n
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
Joey Hess <[EMAIL PROTECTED]> writes:
> Chris Waters wrote:
> > I think people are becoming too ready to propose grand, sweeping
> > changes to policy in order to fix obscure, minor problems.
> I agree.
> > If you *really* want something in policy, I'd suggest: "the package
> > description shoul
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
53 matches
Mail list logo
