On Tue, Sep 07, 1999 at 08:24:06AM -0400, Ben Collins wrote:
> Ok, this is my last attempt for a crowd pleaser. This new an improved
> proposal should satisfy any and all complaints (as few as they were).
> This new proposal has several added features.
I still think this makes the whole recommenda
On Tue, Sep 07, 1999 at 04:02:30PM +1000, Anthony Towns wrote:
> You asked ``How should we change -policy to conform to the constitution?''
> We said ``We shouldn't.'' and gave reasons. How do you want this to be
> more specific?
That's not really what I asked, and that's not how I interpreted the
On Tue, Sep 07, 1999 at 05:38:03PM +0200, Roman Hodek wrote:
> You forgot the case of recompilations: If default is with -g + strip
> (as policy currently recommends), a lot of time is wasted on the
> auto-builder machines.
I think something like the following would work for auto-builder machines:
On Wed, Sep 08, 1999 at 12:34:27AM +0200, Wichert Akkerman wrote:
> I think what Raul wants mostly is some way to incorporate the way
> debian-policy works currently with the structure as layed out in the
> constitution. As his position as chairman of the ctte that is not an
> unlogical desire.
Ba
Look guys, I have a responsibility to see that policy is right.
And so do you.
I understand that a number of you are more than a little hostile towards
the technical committee -- I'm guessing that you don't want some random
group stepping on your work.
But, for the immediate future it doesn't rea
On Tue, Sep 07, 1999 at 06:12:07PM -0400, Ben Collins wrote:
> Umm, what about libraries that purposely compile -dbg packages? This
> is a silly idea, it's not a good idea for the autobuilders to muck
> around with the way the package is meant to be built.
Good point.
Of course, this is solvable
On Tue, Sep 07, 1999 at 09:37:19PM -0400, Ben Collins wrote:
> Umm, how do you see your hack as a speed gain when it requires every
> invocation of gcc to also invoke perl?!
I guess that means you didn't read the rest of the message.
It's trivial to rewrite in C, and I offered to do so.
> So you
On Wed, Sep 08, 1999 at 01:58:54PM +1000, Anthony Towns wrote:
> Huh? As in "Build-Depends: gcc (= 2.7.2)" ? How's this different to
> Bug#41232? Or, rather, how is Bug#41232 lacking?
Bug#41232 is good, though [to take the example from the most recent
message], I still don't see that specifying al
On Wed, Sep 08, 1999 at 02:52:59PM +0200, Marcus Brinkmann wrote:
> This is why I think a suggestion is too weak. You can equally well remove
> the suggestion, because I can't rely on it and have to check always if a
> package follows the policy suggestion or does it differently.
No.
You can alwa
On Wed, Sep 08, 1999 at 09:39:23AM -0400, Raul Miller wrote:
> You can always build with DEB_DEBUG_OPTIONS=debug and expect that the
> executables created will have debug symbols. This is already true even
> without this policy being implemented.
Correction: this is true for some pac
On Wed, Sep 08, 1999 at 08:32:16AM -0400, Ben Collins wrote:
> Raul, you seem to have no real interest in this proposal.
I do have an interest -- I'm not concerned about the speed benefits,
but I very much do have an interest.
In particular, I care about:
(1) impact on my packages,
(2) impact
On Wed, Sep 08, 1999 at 10:12:28AM -0400, Ben Collins wrote:
> > (1) impact on my packages,
>
> The proposal will not force you to change anything.
Why are you saying this?
Earlier instances of the proposal were advertised as requiring a change.
Future instances of the proposal may also, as migh
On Wed, Sep 08, 1999 at 05:30:09PM +0200, Marcus Brinkmann wrote:
> > You can always build with DEB_DEBUG_OPTIONS=debug and expect that the
> > executables created will have debug symbols. This is already true even
> > without this policy being implemented.
>
> This is true now, but with the prop
On Thu, Sep 09, 1999 at 02:19:36AM +0200, Marcus Brinkmann wrote:
> Raul, how hard do you want to make it for users to build with debugging
> info? Activating a gcc wrapper, changing install and strip. This is
> completely unreasonable.
I think I could build you a package which does this for you i
On Thu, Sep 09, 1999 at 08:42:18PM +0200, Marcus Brinkmann wrote:
> Yes, and I acknowledge your goal. But I am concerned that people will just
> drop the -g without replacement, and the rest choose the suggested way or
> another. What I would like to see is to have some unified way to pass build
>
On Thu, Sep 09, 1999 at 07:18:05AM -0700, Jim Lynch wrote:
> perl invocation per gcc invocation?? You Better Let Users Turn It OFF.
> Do not depend on everyone wanting it, whatever it does (did you notice
> that: I don't KNOW what it does, nor do I CARE.)
>
> You can consider this a second SO LONG
On Fri, Sep 10, 1999 at 01:25:25AM +0200, Marcus Brinkmann wrote:
> Mmh. I see your point. What about having "debug" and "strip"? This would
> allow for:
>
> DEB_DEBUG_OPTION=debug nostrip # Build debug packages.
> DEB_DEBUG_OPTION=debug # Build debug files, but strip them in package.
>
>
Can we get liblockfile's program an routines to reliably *fail* when
it's locking an nfs file?
If so, perhaps we can recommend Maildir/ for people who need to
put mail on an nfs partition.
The bad side of this is that it requires some very specific documentation,
and it's an extra admin headache
On Fri, Sep 10, 1999 at 01:32:33PM +0200, Roland Rosenfeld wrote:
> There are some disadvantages with this proposal:
...
You're right: there are resource consumption costs. However, when
measured against lost or damaged mail issues, these are probably worth
incurring.
> > The bad side of this is
On Fri, Sep 10, 1999 at 11:46:05AM +0200, Miquel van Smoorenburg wrote:
> Bad idea. Why do you want to share a mail spool over NFS? Because
> there's another machine that wants to access the mail, or the mail
> is stored on another machine and you want to access it. That other
> machine might well
On Tue, Sep 14, 1999 at 07:58:28PM +0200, Stefan Gybas wrote:
> if [ -d /usr/doc/libapache-mod-jserv -a \
> ! /usr/doc/libapache-mod-jserv -ef
>/usr/share/doc/libapache-mod-jserv ]; then
>
> rm -f /usr/doc/libapache-mod-jserv/.dhelp
> rmdir --ignore-fail-on-non-empty /usr/doc/
On Sat, Sep 18, 1999 at 01:23:53PM -0700, Seth R Arnold wrote:
> (Actually, if there is any easy way to use the debian package
> management system to find out this info, I suppose that would make me
> more than happy...)
Sadly, there's no ready reference for all the various interfaces
which have e
> On Sep 18, Joseph Carter wrote:
> > It's a problem if there's no transition to speak of. We apparently have
> > decided not to make policy that makes a bunch of packages instantly non-
> > compliant without a reasonable transition.
On Sat, Sep 18, 1999 at 11:24:13PM -0500, Chris Lawrence wrote:
On Sun, Sep 19, 1999 at 12:45:10AM -0500, Chris Lawrence wrote:
> My point is simply that changing policy does not translate into making
> things happen by fiat. Perhaps you missed the entire point of my
> mail, because it seems like we agree with each other.
*blush* yeah.
--
Raul
On Sun, Sep 19, 1999 at 12:45:10AM -0500, Chris Lawrence wrote:
> My point is simply that changing policy does not translate into making
> things happen by fiat. Perhaps you missed the entire point of my
> mail, because it seems like we agree with each other.
Actually... rereading your original p
On Sun, Sep 19, 1999 at 08:25:32PM -0500, Steve Greenland wrote:
> Yech. What's wrong with 'dpkg -S /etc/profile'?
I suppose I should have used /etc/ftpusers as my example.
However, you're right: dpkg -S gets it right most of the time.
--
Raul
Hi,
I've seen some people claim that the FHS transition issue has been
handled, but we still don't have a policy for it. I personally don't
feel comfortable drafting a policy but I will if no one else does.
At the moment, there does not even exist a /usr/doc/lintian, and people
are still dealing
On Mon, Sep 20, 1999 at 03:59:13PM +0300, Antti-Juhani Kaijanaho wrote:
> On Sun, Sep 19, 1999 at 11:03:05PM -0400, Raul Miller wrote:
> > I've seen some people claim that the FHS transition issue has been
> > handled, but we still don't have a policy for it.
>
>
On Mon, Sep 20, 1999 at 10:33:55AM -0400, Brian White wrote:
> As such, I think Debian's system should be altered a bit. I recommend using
> instead the name "/cgi-lib/" for scripts under /usr/lib/cgi-bin/. This
> will keep both features independant and not affect the general use of
> the system.
On Wed, Sep 22, 1999 at 11:32:23AM +0100, Philip Hands wrote:
> I think we should agree to do absolutely nothing with the /opt
> directory, other than create it.
I suggest that we create whatever [empty] directory structure FHS
specifies.
FHS 2.0 specifies the following directories:
/etc/opt
/op
On Wed, Sep 22, 1999 at 10:29:20AM -0700, Chris Waters wrote:
> Well, 2.0 and the 2.1 both say that these dirs are a) reserved for
> local sysadmin use, and, more importantly, b) packages "shall function
> normally in the absence of these reserved directories."
While that's true, I think it's impo
On Wed, Sep 22, 1999 at 11:05:36PM +0200, Andreas Voegele wrote:
> In my opinion, the installation guide should suggest creating an /opt
> partition if the user intends to install commercial software like
> Applixware, Civilization or the Oracle RDBMS, but nothing else should
> be done.
What probl
On Wed, Sep 22, 1999 at 04:18:07PM -0700, Chris Waters wrote:
> Oh c'mon. You're talking about people who are smart enough to create
> symlinks in /opt/bin, but aren't smart enough to create the dir in the
> first place? I don't buy it. :-)
The issue isn't that they don't know how to create dir
On Wed, Sep 22, 1999 at 05:51:09PM -0700, Chris Waters wrote:
> There was nothing stopping them from creating links in /usr/local/bin
> either -- why would they get the hint all of a sudden from /opt/bin
> when they didn't from /usr/local/bin? I think that /opt/bin is a bad
> idea in the first pla
On Wed, Sep 22, 1999 at 10:29:36PM -0700, Chris Waters wrote:
> Yes, I've read chapter 2, and I just reread it. What about it? I see
> nothing there that contradicts what I said above. Both /usr (including
> /usr/local) and /opt are static and sharable, so what's the problem?
Oops, I misremembered
On Thu, Sep 23, 1999 at 10:19:04AM +0200, Andreas Voegele wrote:
> You suggest creating the following directories by default:
>
> /etc/opt, /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib,
> /opt/man and /var/opt.
Yes.
> Firstly, none of the existing applications that go to /opt use these
On Thu, Sep 23, 1999 at 11:24:37AM +0100, Philip Hands wrote:
> It strikes me that if all the distributions include these directories
> by default, that ISV installer writers will put stuff like:
>
> for i in $PACKAGE_DIR/bin/* ; do ln -s $i /opt/bin ; done
>
> in their install scripts. This i
On Thu, Sep 23, 1999 at 03:03:52PM +0100, Philip Hands wrote:
> I think we should create /opt because the FHS requires it, and
> possibly /opt/README.debian if the FHS allows it, but nothing more.
FHS doesn't allow us to create /opt/README.debian, at least not
without getting the sysadmin to be in
On Thu, Sep 23, 1999 at 11:55:09AM -0700, Chris Waters wrote:
> And in any case, I meant wrong in the moral sense, not the legal
> sense.
I don't see that that's a meaningful distinction for this case.
--
Raul
On Fri, Sep 24, 1999 at 11:34:28PM -0500, The Doctor What wrote:
> I do not like the idea of a daemon starting up with a default
> configuration that I have not double checked upon installation. I
> consider automatically starting with no choice a misfeature.
I think I agree.
I got a rude start
Raul Miller <[EMAIL PROTECTED]> wrote:
> > Perhaps there are people who want a "service enabled by default" policy,
> > and perhaps we should accomodate them. However, I'm not one of them
> > and I don't want any services turned on on some of my machi
On Tue, Sep 28, 1999 at 04:23:22PM -0400, Peter S Galbraith wrote:
> Then we'll have to agree where we register docs. I have the
> following directories on a fresh potato system (with few packages):
>
> /usr/share/doc/HTML/
> /usr/doc/HTML/
>
> And they are _not_ symlinks. They get created by d
On Wed, Sep 29, 1999 at 09:57:53PM +1000, Drake Diedrich wrote:
>One way to minimize the harm of unintentionally installed or
> misconfigured daemons would be to add a default ipchain/ipfwadm policy
> rejecting all TCP SYN (incoming initialization) and non-DNS UDP packets
> except those from lo
On Tue, Aug 31, 1999 at 12:49:20PM -0500, Chris Lawrence wrote:
> Drawing the line between technical and policy decisions, though, is a
> lot like splitting the Gordian knot.
As in, a simple sword stroke would do? ;)
To avoid people fretting too much about this issue, here's what
I think I'm goi
On Sat, Oct 02, 1999 at 06:05:53PM +1000, Herbert Xu wrote:
> Here's a quote from the policy:
>
> `Non-free' contains packages which are not compliant with the DFSG or
> which are encumbered by patents or other legal issues that make their
> distribution problematic.
Encumbered by
across international borders.
- Forwarded message from Joseph Carter <[EMAIL PROTECTED]> -
X-Envelope-Sender: [EMAIL PROTECTED]
Date: Sat, 2 Oct 1999 13:12:57 -0700
From: Joseph Carter <[EMAIL PROTECTED]>
To: Raul Miller <[EMAIL PROTECTED]>
Cc: Herbert Xu <[EMAIL PR
>
>if [ -x /usr/sbin/update-mime ]; then
>update-mime
>fi
>
Seconded.
[As far as I can tell, you're documenting existing practice.]
--
Raul
On Wed, Oct 13, 1999 at 07:33:53PM -0500, Nathan E Norman wrote:
> What's inelegant about sudo?
It creates (and waits for) dns traffic every time it's run.
In some circumstances this means sudo just hangs.
--
Raul
On Thu, Oct 14, 1999 at 07:20:05PM +, Lars Wirzenius wrote:
> /usr/doc/debian-policy/policy.html/index.html:
>
> Copyright ©1996,1997,1998 Ian Jackson and Christian Schwarz.
>
> Yet the manual has been modified by others since. Should the copyright
> be updated?
Briefly: yes.
--
Ra
On Wed, Oct 20, 1999 at 07:04:19PM +0100, Julian Gilbey wrote:
> > On Thu, Oct 14, 1999 at 07:20:05PM +, Lars Wirzenius wrote:
> > > /usr/doc/debian-policy/policy.html/index.html:
> > >
> > > Copyright (c)1996,1997,1998 Ian Jackson and Christian Schwarz.
> > >
> > > Yet the manual has
The one issue I can see is existing support for source packages.
We should not allow bz2 source packages into our archives until after
the source package tools have a good track record with transparently
supporting this format.
[Specifically, I'd like to build some of my packages to support bz2,
I wrote:
> Probably the best option would be to indicate copyrights as being jointly
> held by each person who's made a contribution. [Just list copyright,
> one after another, with each person's name on it.]
>
> Another option would be to grant the copyright to SPI. [If people agreed
> to this.
On Sat, Oct 23, 1999 at 04:25:06PM -0400, Ben Collins wrote:
> If anything, this needs to be restricted to a package in "experiemental",
> not in any of the main archives. That way there is no chance of some
> saying "well the option was there, I didn't know we didn't actually
> support it yet, so
On Sun, Oct 24, 1999 at 02:11:36AM +0300, Antti-Juhani Kaijanaho wrote:
> On Sat, Oct 23, 1999 at 04:51:17PM -0400, Raul Miller wrote:
> > The original copyright holder on the document still holds the copyright
> > so for the moment it should just be copyright Ian Jackson.
&g
On Sat, 23 Oct 1999 at 19:13, Raul Miller wrote:
> > > The original copyright holder does not own the copyright to those
> > > parts of the document he did not write.
> > He does, however, own the copyright on the document as a whole.
> > Fun, eh?
On Sun, Oct 24, 1
Package: debian-policy
Version: 3.0.1.1
Severity: wishlist
I'm tired of defending the current situation where debian policy specifies
POSIX behavior for /bin/sh, but echo -n has widespread use in the Linux
community (including especially debian policy, the linux kernel source,
many debian scripts,
On Mon, Oct 25, 1999 at 02:31:42PM +1000, Herbert Xu wrote:
> What about escape codes, do we require them or do we forbid them?
I think it would be a bad idea to make any recommendations on
escape codes in debian policy:
(1) We don't use them.
(2) In almost all examples we don't care if they're
On Mon, Oct 25, 1999 at 02:54:00PM +1000, Herbert Xu wrote:
> When I said escape codes, I really meant the scripts that currently
> use them with/without -e. So with your current modification to the
> policy, escape codes are no longer allowed in any #!/bin/sh script.
> Remember the kernel source
On Mon, Oct 25, 1999 at 02:54:00PM +1000, Herbert Xu wrote:
> Currently bash and ash supports -e in violation to POSIX.
Rereading my copy of chapter 4.19 of the POSIX 1003.2 draft:
4.19.3 Options
The echo utility shall not recognize the -- argument in the manner
specified by utility syntax
On Mon, Oct 25, 1999 at 01:36:26AM -0400, Raul Miller wrote:
> > Rereading my copy of chapter 4.19 of the POSIX 1003.2 draft:
> >
> >
> > 4.19.3 Options
> >
> > The echo utility shall not recognize the -- argument in the manner
> > specifie
On Mon, Oct 25, 1999 at 04:51:42PM +1000, Herbert Xu wrote:
> IMHO it does. Firstly it's clear from the wording that all "options"
> come under the operands category.
It's clear from the wording that only for the -- option is this behavior
guaranteed.
--
Raul
On Mon, Oct 25, 1999 at 09:08:51PM +1000, Herbert Xu wrote:
> So, unless the first operand is -n, or if the string contains backslash
> characters, the operands are to be written to the standard output verbatim
> separated by sngle spaces with a new line at the end. If the first operand
> is -n, o
On Mon, Oct 25, 1999 at 10:06:24PM +1000, Herbert Xu wrote:
> Let me state once again, this has no bearing whatsoever over the proposed
> change in policy and my question about whether escape codes/-e are to be
> mentioned or not. It is for purely pendantic value.
I think it's an important point,
On Tue, Oct 26, 1999 at 12:14:19AM +0100, Julian Gilbey wrote:
> I'm about to add #41232 (source dependencies) to the next policy
> version. But will this break existing tools? In particular, will the
> dpkg* tools yet be able to build a package using a Source-Depends:
> field, or will they die?
ntic value.
On Mon, Oct 25, 1999 at 08:09:13PM -0400, Raul Miller wrote:
> > I think it's an important point, because getting it wrong would have
> > all sorts of nasty implications.
On Tue, Oct 26, 1999 at 10:11:50AM +1000, Herbert Xu wrote:
> But do you agree that with your curren
On Tue, Oct 26, 1999 at 11:39:06AM +0100, Julian Gilbey wrote:
> We spent a lot of time on this list thrashing out the /var/spool/mail
> vs. /var/mail issue. It would be a shame if it came to nothing due to
> a lack of seconds. Please check up this final proposal (included
> below) and second it
[I've elected not to Cc: debian-devel]
On Tue, Oct 26, 1999 at 08:32:18PM -0400, Chris Pimlott wrote:
> There's still problems with using pre-depends to make sure bzip2
> is installed.
If we decide to use bzip2 in this capacity the package should be
required and essential.
--
Raul
On Tue, Oct 26, 1999 at 10:16:05PM -0700, Joel Klecker wrote:
> It's also been suggested that --rename is potentially harmful.
--rename would be harmful if the divert target would be the /bin/sh
symlink. [Or some other target which is critical to system integrity.]
In almost all other circumstan
On Wed, Oct 27, 1999 at 03:35:40PM +0300, Antti-Juhani Kaijanaho wrote:
> Well, if the metapackage is in the available file, the following
> shell code will create such written list (untested):
...
Last time I checked, apt-get update did not update the available file.
--
Raul
Julian Gilbey wrote:
> > Reading bug #31645, it seems clear that the Packaging Manual was
> > accepted as policy, although Joey had reservations.
> >
> > Should I go ahead and make the modifications Manoj proposed?
On Tue, Oct 26, 1999 at 09:42:54PM -0700, Joey Hess wrote:
> I continue to disagre
On Tue, Oct 26, 1999 at 10:01:58PM -0700, Joel Klecker wrote:
> [ Note: quoting the entire thing since this may have been missed due
> to lame original subject ]
Sorry about that.
Thanks,
--
Raul
[I've chosen to Bcc: debian-devel because the debian-devel side of
this thread is getting out of hand.]
On Wed, Oct 27, 1999 at 04:30:07PM +0200, Joost Kooij wrote:
> > If a script requires
> > non-POSIX features from the shell interpreter, the appropriat
On Thu, Oct 28, 1999 at 04:26:50PM +0200, Roland Rosenfeld wrote:
> I proposed to change the "Manual pages" section of our policy to get
> rid of the undocumented(7) symlinks.
I agree that this is a good idea (I'm seconding it).
--
Raul
On Sun, Nov 21, 1999 at 12:49:02PM +1000, Anthony Towns wrote:
> From: Joel Klecker <[EMAIL PROTECTED]>
...
> +Further, since these packages may be implicitly required by any
> +number of other packages, including dpkg itself, they must function
> +correctly even while unconfigured.
Se
I'm Cc'ing this message to debian-apt, to ask if the following
addittion to policy has any hidden ramifications that might
make it a bad idea.
On Tue, Nov 23, 1999 at 03:25:00PM +0100, Santiago Vila wrote:
> On Tue, 23 Nov 1999, Anthony Towns wrote:
>
> > +Since dpkg will upgrade other packag
On Tue, Nov 23, 1999 at 02:54:56PM +, Julian Gilbey wrote:
> But: I just realised. For bash (or whatever essential packages
> provide /bin/sh and /bin/perl), the situation is far worse: what
> happens if a package is *removed* when the symlink is not in place
> (because the package is not prop
On Thu, Nov 25, 1999 at 10:17:43PM -0500, Brian Mays wrote:
> Besides, is it so difficult to do "dpkg -L pccts"? If you want a list
> of the binaries, then try "dpkg -L pccs | grep bin".
Yes, people should know about dpkg -L in their quest for package level
documentation.
Not only will it show y
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.
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
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, 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
I second Wichert's proposal that policy recommend
non-free package Enhances: free package, in place of
free package Suggests: non-free package.
--
Raul
-nonfree, where the
> >> "Enhances" is for one-and-only-one package, but it doesn't work for
> >> the great majority of cases.
Raul Miller <[EMAIL PROTECTED]> writes:
> Raul> That's solvable: create a virtual package which has a free instance
>
> 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
> > 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 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
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 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, 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
> 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
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
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
> > > 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&
> [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.
>
>
> > 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 a
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> 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 12:08:07PM +0100, Falk Hueffner wrote:
> "Category" sounds a bit as if it was refering to the function of the
> packages. I'd suggest "area". With "distribution" I'd connected those
> thingies like "slink" or "bo".
"area" also has the advantage of being consistent terminolo
Branden Robinson <[EMAIL PROTECTED]> writes:
> > So, I propose the following compromise:
> >
> > * Downgrade xfree86-common and xlib6g from standard to optional; AND
> > * Modify section 5.8 to say that creating X and non-X versions of a
> > package is permissible *ONLY* if the non-X versi
On Thu, Dec 02, 1999 at 09:21:51PM +0100, Tomasz Wegrzanowski wrote:
> I know, this will be highly controversive :
>
> SERIOUS SUGGESTION FOR WOODY :
> we should get rid of all gif-making packages except 1 package
> a2gif in non-free, which will allow you to convert other images to gifs if
> you R
101 - 200 of 407 matches
Mail list logo