Re: virtual package 'ispell-dictionary'

1999-08-02 Thread Julian Gilbey
> I hereby formally propose that we add ispell-dictionary to the list of > virtual packages for "Anything providing a dictionary suitable for > ispell". > > I am now looking for seconds for this proposal. Seconded. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Bug#40706: Reasons for not moving at all

1999-08-02 Thread Timothy Baldwin
In message <[EMAIL PROTECTED]> Gordon Matzigkeit <[EMAIL PROTECTED]> wrote: > Marcus's argument here is most compelling. It is not the present cost > of Manoj's proposal that is prohibitive, it is the future cost of all > those prerm scripts. And so, I formally object to this proposal.

Re: Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

1999-08-02 Thread Jason Gunthorpe
On Mon, 2 Aug 1999, Roman Hodek wrote: > > > Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your > > friend. > > If it makes you lucky, think the vars re-named :-) But it really makes > no difference, I meant exactly the same as you, i.e. ARCH == cpu. > > > Looks good to me. I don'

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

1999-08-02 Thread Stefan Gybas
Roman Hodek wrote: > The prefix idea is good, here a suggestion for concrete syntax: I´d prefer a syntax in the style of /etc/exports, e.g. Build-Depends: package1, package2(CPU1), package3(!CPU1), package4(SYSTEM2-CPU2, SYSTEM3-*), package5 | package6(CPU1), package7(CPU1, >= 2.0), package7(

Bug#42358: policy says /var/lib/games, FHS says /var/games

1999-08-02 Thread Chris Waters
Package: debian-policy Version: 3.0.1.0 In section 5.10, the first paragraph mentions /var/lib/games. The FHS has moved this directory to /var/games. I suggest a) correcting this, and b) mentioning that programs which use /var/lib/games should switch. Old: "The permissions on /var/lib/games

Re: /usr/share/doc: some new proposals

1999-08-02 Thread Chris Waters
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > On Sun, Aug 01, 1999 at 02:05:17PM +1000, Anthony Towns wrote: > > > DELAYED DO-NOTHING (the Bad One) > > Honestly, I don't even think this is that bad. > > > > Anyway, I think the more important part of this discussion, or at > > least the more co

Re: /usr/share/doc: some new proposals

1999-08-02 Thread Chris Waters
Anthony Towns writes: > > DELAYED DO-NOTHING (the Bad One) > Honestly, I don't even think this is that bad. Ok, a couple of other people have said the same thing, and so maybe it's not so bad. Maybe the best way to deal with the symlink idea is to make it optional (after potato), and entirely

Re: /var/lib, /var/mail

1999-08-02 Thread Joseph Carter
On Mon, Aug 02, 1999 at 05:28:05PM +0200, Santiago Vila wrote: > > What I am objecting to is wording in policy to the effect that we should > > do something, followed by "don't do this for potato". Especially if it > > doesn't really matter if it's done for potato or not. > > So maybe we both agr

Re: /usr/share/doc vs. /usr/doc transition, debate reopened

1999-08-02 Thread Joseph Carter
On Mon, Aug 02, 1999 at 04:06:15PM +0200, [EMAIL PROTECTED] wrote: > Thanks for reopening the debate, Chris. > > I am (still) following it and I (still :) do not understand what is wrong > with the following' > > debian-policy [PROPOSAL]: /usr/doc -> /usr/share/doc should be a symlink > > I prop

Re: Bug#40706: usr/share/doc vs. /usr/doc

1999-08-02 Thread Santiago Vila
On Sat, 31 Jul 1999, Joey Hess wrote: > Santiago Vila wrote: > > I would like you to elaborate on that. I think it makes sense that the > > more difficult the migration process is, the longer it will take, and your > > proposal complicate things in a considerable degree. > > That's simply not so.

Re: /usr/share/doc (was Re: weekly policy summary)

1999-08-02 Thread Santiago Vila
On Fri, 30 Jul 1999, Roland Rosenfeld wrote: > On Fri, 30 Jul 1999, Joseph Carter wrote: > > > > 1. mv /usr/doc/* /usr/share/doc > > This isn't trivial, because you cannot be sure that /usr/doc and > /usr/share/doc are located at the same filesystem. > And don't miss the (few) packages which alr

Re: virtual package 'ispell-dictionary'

1999-08-02 Thread Santiago Vila
On Sun, 1 Aug 1999, Julian Gilbey wrote: > > Hi, > > >>"Julian" == Julian Gilbey <[EMAIL PROTECTED]> writes: > > > > >> What exactly is required to "resurrect" a proposal? Is it required to > > wait > > >> some amount of time since it was rejected? > > > > Julian> I don't know. Sufficient i

Re: /usr/share/doc (was Re: weekly policy summary)

1999-08-02 Thread Marcus Brinkmann
On Mon, Aug 02, 1999 at 10:57:12AM +1000, Anthony Towns wrote: > On Sun, Aug 01, 1999 at 06:08:33PM +0200, Marcus Brinkmann wrote: > > On Sat, Jul 31, 1999 at 01:50:39AM +1000, Anthony Towns wrote: > > > > So all new packages will have to depend on this particular version of > > > > base-files or n

Re: /usr/share/doc (was Re: weekly policy summary)

1999-08-02 Thread Marcus Brinkmann
On Fri, Jul 30, 1999 at 04:54:07PM +1000, Anthony Towns wrote: > > postinst install: ^^^ also at upgrade. > if [ -d /usr/doc ]; then > if [ ! -e /usr/doc/$package -a -d /usr/share/doc/$package ]; then > ln -s /usr/share/doc/$package

Re: /var/lib, /var/mail

1999-08-02 Thread Santiago Vila
On Fri, 30 Jul 1999, Joseph Carter wrote: > [...] > What I am objecting to is wording in policy to the effect that we should > do something, followed by "don't do this for potato". Especially if it > doesn't really matter if it's done for potato or not. So maybe we both agree that a policy which

/usr/share/doc vs. /usr/doc transition, debate reopened

1999-08-02 Thread Kristoffer . Rose
Thanks for reopening the debate, Chris. I am (still) following it and I (still :) do not understand what is wrong with the following' debian-policy [PROPOSAL]: /usr/doc -> /usr/share/doc should be a symlink I propose that the "transition" of /usr/doc to /usr/share/doc be done with the following

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

1999-08-02 Thread Richard Braakman
Are the -Conflicts headers really necessary? So far I have not been able to think of a use for them, and they complicate the task of the build daemons ("install everything needed to build this package") unnecessarily. We've already seen with binary dependencies that the Conflicts relationships cr

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

1999-08-02 Thread Roman Hodek
> Your naming is weird ;) s/ARCH/CPU/, s/OS/SYSTEM/ and I'm your > friend. If it makes you lucky, think the vars re-named :-) But it really makes no difference, I meant exactly the same as you, i.e. ARCH == cpu. > Looks good to me. I don't know how many logical operators we should > support, but

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

1999-08-02 Thread Marcus Brinkmann
On Mon, Aug 02, 1999 at 11:36:19AM +0200, Roman Hodek wrote: > > > This shouldn't be too hard. You only need a syntax for it. There are several > > possibilities: > > > > Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, > > linux-all:kernel-headers-2.0.36 > > The prefix idea is good, her

Bug#41232: debian-policy: [PROPOSAL] Build-time dependencies on binary packages

1999-08-02 Thread Roman Hodek
> This shouldn't be too hard. You only need a syntax for it. There are several > possibilities: > > Build-Depends: hurd-all:gnumach-dev, hurd-all:hurd-dev, > linux-all:kernel-headers-2.0.36 The prefix idea is good, here a suggestion for concrete syntax: ARCH:packagerestricted to ARCH

Re: policy summary for past two weeks

1999-08-02 Thread Joseph Carter
On Sun, Aug 01, 1999 at 06:42:36PM -0300, Nicolás Lichtmaier wrote: > > I'm almost at the point that I'm ready to agree with the small and growing > > group of people who are saying screw the transition---the only thing it > > really hurts is /usr/doc/pac and being a creature of habit that > > anno

Re: /usr/share/doc (was Re: weekly policy summary)

1999-08-02 Thread Anthony Towns
On Sun, Aug 01, 1999 at 06:08:33PM +0200, Marcus Brinkmann wrote: > On Sat, Jul 31, 1999 at 01:50:39AM +1000, Anthony Towns wrote: > > > So all new packages will have to depend on this particular version of > > > base-files or newer, or there is still no guarantee that the link gets > > > removed.