Bug#43787: changed title, and remade the proposed change

1999-09-07 Thread Raul Miller
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

Re: Policy about policy

1999-09-07 Thread Raul Miller
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

efficient use of auto-builder machines (was Re: Bug#43787: changed title, and remade the proposed change)

1999-09-07 Thread Raul Miller
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:

Re: Policy about policy

1999-09-07 Thread Raul Miller
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

Enough already (was Re: Policy about policy)

1999-09-08 Thread Raul Miller
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

Re: efficient use of auto-builder machines (was Re: Bug#43787: changed title, and remade the proposed change)

1999-09-08 Thread Raul Miller
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

Re: efficient use of auto-builder machines (was Re: Bug#43787: changed title, and remade the proposed change)

1999-09-08 Thread Raul Miller
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

Re: efficient use of auto-builder machines (was Re: Bug#43787: changed title, and remade the proposed change)

1999-09-08 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-08 Thread Raul Miller
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

[corrections to my last post] Re: Bug#43787: changed title, and remade the proposed change

1999-09-08 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-08 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-09 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-09 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-09 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-09 Thread Raul Miller
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 >

gcc cover wasn't a policy proposal (was Re: PLEASE, ENOUGH)

1999-09-09 Thread Raul Miller
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

Re: Bug#43787: changed title, and remade the proposed change

1999-09-10 Thread Raul Miller
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. > >

Re: Bug#43529: debian-policy: mail locking in Debian is _not_ NFS safe

1999-09-10 Thread Raul Miller
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

Bug#43529: debian-policy: mail locking in Debian is _not_ NFS safe

1999-09-10 Thread Raul Miller
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

Re: Bug#43529: debian-policy: mail locking in Debian is _not_ NFS safe

1999-09-10 Thread Raul Miller
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

Re: How to migrate from /usr/doc to /usr/share/doc

1999-09-14 Thread Raul Miller
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/

Bug#45406: PROPOSAL] Config files must have manpages

1999-09-19 Thread Raul Miller
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

Re: On Policy Compliance (was Re: static user IDs)

1999-09-19 Thread Raul Miller
> 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:

Re: On Policy Compliance (was Re: static user IDs)

1999-09-19 Thread Raul Miller
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

Re: On Policy Compliance (was Re: static user IDs)

1999-09-19 Thread Raul Miller
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

Bug#45406: PROPOSAL] Config files must have manpages

1999-09-20 Thread Raul Miller
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

fhs transition issue

1999-09-20 Thread Raul Miller
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

Re: fhs transition issue

1999-09-20 Thread Raul Miller
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. > >

Re: [PROPOSED] Split /cgi-bin/ into system and local parts

1999-09-20 Thread Raul Miller
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.

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-22 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-22 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-22 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: [forward] FHS pre-2.1 draft #3 on web site

1999-09-23 Thread Raul Miller
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

Re: Packages should not Conflict on the basis of duplicate functionality

1999-09-25 Thread Raul Miller
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

Re: Packages should not Conflict on the basis of duplicate functionality

1999-09-27 Thread Raul Miller
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

Re: Re^2: strange behavior of dh_dhelp

1999-09-29 Thread Raul Miller
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

Re: Packages should not Conflict on the basis of duplicate functionality

1999-09-30 Thread Raul Miller
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

Re: Senseless Bickering and Overpoliticization

1999-09-01 Thread Raul Miller
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

Re: SSH never free

1999-10-02 Thread Raul Miller
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

Bug#46522: [knghtbrd@debian.org: Re: SSH never free]

1999-10-03 Thread Raul Miller
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

Bug#46516: PROPOSAL] MIME support sub-policy

1999-10-03 Thread Raul Miller
> >if [ -x /usr/sbin/update-mime ]; then >update-mime >fi > Seconded. [As far as I can tell, you're documenting existing practice.] -- Raul

Re: Proposal of new group

1999-10-14 Thread Raul Miller
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

Bug#47438: copyright statement needs updating?

1999-10-14 Thread Raul Miller
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

Bug#47438: copyright statement needs updating?

1999-10-23 Thread Raul Miller
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

Bug#39299: AMENDED PROPOSAL] Permit use of bz2 for source packages

1999-10-23 Thread Raul Miller
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,

Bug#47438: copyright statement needs updating?

1999-10-23 Thread Raul Miller
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.

Bug#39299: AMENDED PROPOSAL] Permit use of bz2 for source packages

1999-10-23 Thread Raul Miller
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

Bug#47438: copyright statement needs updating?

1999-10-23 Thread Raul Miller
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

Bug#47438: copyright statement needs updating?

1999-10-24 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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,

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-25 Thread Raul Miller
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

Bug#48247: echo -n

1999-10-26 Thread Raul Miller
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,

Re: Source dependencies: are we ready?

1999-10-26 Thread Raul Miller
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?

Bug#48247: echo -n

1999-10-26 Thread Raul Miller
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

Bug#42052: var/spool/mail and /var/mail

1999-10-26 Thread Raul Miller
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

Re: Suggestion to and how to alow different compression for .debs

1999-10-27 Thread Raul Miller
[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

Bug#29522: marked as done ([PROPOSED]: clarification needed about diversions)

1999-10-27 Thread Raul Miller
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

Re: Source dependencies: are we ready?

1999-10-27 Thread Raul Miller
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

Re: Packaging Manual is policy

1999-10-27 Thread Raul Miller
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

Bug#46522: PROPOSAL] Amend non-free definition (was: Re: Bug#46522: [knghtbrd@debian.org: Re: SSH never free])

1999-10-27 Thread Raul Miller
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

Bug#48247: [PATCH] latest ash has broken 'echo' command

1999-10-27 Thread Raul Miller
[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

Bug#39830: AMENDMENT]: get rid of undocumented(7) symlinks

1999-10-29 Thread Raul Miller
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

Bug#50832: PROPOSED] Clarify meaning of Essential: yes

1999-11-21 Thread Raul Miller
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

Bug#50832: AMENDMENT] Clarify meaning of Essential: yes

1999-11-23 Thread Raul Miller
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

Bug#50832: AMENDMENT] Clarify meaning of Essential: yes

1999-11-23 Thread Raul Miller
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

Bug#51262: Suggestion: Packages should carry a manpage

1999-11-26 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-29 Thread Raul Miller
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.

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-29 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-29 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-29 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-30 Thread Raul Miller
I second Wichert's proposal that policy recommend non-free package Enhances: free package, in place of free package Suggests: non-free package. -- Raul

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-30 Thread Raul Miller
-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 >

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-11-30 Thread Raul Miller
> 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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
> > 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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
> 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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-01 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-02 Thread Raul Miller
> > > 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&

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-02 Thread Raul Miller
> [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. > >

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-02 Thread Raul Miller
> > 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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-03 Thread Raul Miller
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

Re: [PROPOSED] Change package relations policy to remove references to non-free from main

1999-12-03 Thread Raul Miller
> 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

Re: a nitpicky reading of policy

1999-12-03 Thread Raul Miller
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

Re: a nitpicky reading of policy

1999-12-03 Thread Raul Miller
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

Re: The end of GIF format [was : Dangerous precedent being set - possible serious violation of the GPL ]

1999-12-03 Thread Raul Miller
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

<    1   2   3   4   5   >