(Cc'ed to Mr FHS, who I suspect's on this list anyway)
On Thu, Jul 29, 1999 at 01:42:33PM -0500, Manoj Srivastava wrote:
> >>"Richard" == Richard Braakman <[EMAIL PROTECTED]> writes:
> Richard> I think it's really nice that Debian has *all* configuration
> Richard> info in the /etc directory, wi
On Thu, Jul 29, 1999 at 07:44:29PM +0300, Antti-Juhani Kaijanaho wrote:
> > I don't want to go and add cruft to the policy that says essentially "This
> > is policy but you shouldn't go out and reupload all of your packages so
> > they do things the new way just because there's a new policy."
>
>
On 28-Jul-99, 21:37 (CDT), Joseph Carter <[EMAIL PROTECTED]> wrote:
> And then there are the people who think that we should just say screw
> backwards compatibility and just move the directories without bothering
> with transition. Unfortunately many of them are already uploading
> packages, whi
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> Please hold off that for a week or so. There are
>> constitutional methods for getting contentious stuff into the plicy
>> document, and this seems like an ideal scenario for one of
Hi,
>>"Antti-Juhani" == Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
Antti-Juhani> On Thu, Jul 29, 1999 at 01:39:14PM -0500, Manoj Srivastava wrote:
>> I think I am beginning to think that the formal objection
>> clause is a mistake. Here you are, cutting off any discussion on
>> this, n
On Thu, Jul 29, 1999 at 10:41:06PM -0500, Manoj Srivastava wrote:
> Chris> It may be too late. We *NEED* consensus on this sort of thing:
> No, we do not need a consensus. The DPL can still mandate a
> solution by fiat, thank god.
What?
Since when is the DPL mandating a solution bett
On Fri, 30 Jul 1999, Anthony Towns wrote:
> FWIW, I don't think forcing all packages to have postinst's and prerm's
> for the rest of eternity to be a particularly good solution either. Are
> there any fundamental problems with using a cronjob instead?
This was just discussed on irc a bit.. Ah,
Anthony Towns writes:
> OTOH, an /etc/share doesn't sound like a bad idea for normal Unix
> programs, and seems much easier to run rdist on than selected
> entries in /etc. I think the FHS (and thus policy) could reasonably
> recommend the use /etc/share/* in this way. Unless there's some
> prior
On Thu, Jul 29, 1999 at 10:52:36PM -0600, Jason Gunthorpe wrote:
> A cronjob is a bad idea because the links will persist for dpkg operations
> and basically cause upgrades/downgrades to fail.
>
> There is no elegant way to piece wise move a directory spanning multiple
> packages with dpkg.
/usr#
On Jul 29, Steve Greenland wrote:
> Another option is to provide a package whose job is monitor the
> directories in /usr/doc and /usr/share/doc, and maintain the
> /usr/doc/ -> /usr/share/doc/ links as needed. A sysadmin who
> needed/wanted the links could install the package, one who doesn't
> wo
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
> Chris> It may be too late. We *NEED* consensus on this sort of thing:
> No, we do not need a consensus. The DPL can still mandate a
> solution by fiat, thank god.
Man, your reading
On Thu, 29 Jul 1999, Joseph Carter wrote:
> /usr# mv doc share/doc/usrdoc
> /usr# ln -s /usr/share/doc/usrdoc doc
>
> dpkg would deal with that and the docs would all be under /usr/share/doc
> (though not /usr/share/doc/${PACKAGE}) which makes things still not as
> ælegant as they should be.
Ho
On Thu, Jul 29, 1999 at 11:25:41PM -0600, Jason Gunthorpe wrote:
> > /usr# mv doc share/doc/usrdoc
> > /usr# ln -s /usr/share/doc/usrdoc doc
> >
> > dpkg would deal with that and the docs would all be under /usr/share/doc
> > (though not /usr/share/doc/${PACKAGE}) which makes things still not as
>
Hi,
>>"Anthony" == Anthony Towns writes:
Anthony> FWIW, I don't think forcing all packages to have postinst's
Anthony> and prerm's for the rest of eternity to be a particularly
Anthony> good solution either.
You don't need it for the rest of eternity. We create the
postinst,
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> >>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> It may be too late. We *NEED* consensus on this sort of thing:
>> No, we do not need a consensus. The DPL can still m
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> Could the people in the CC: field so assign the copyrights?
Chris> I'm not sure mine needs it; my proposal was basically copied (with
Chris> some minor editing) from /usr/doc/menu/
On Fri, Jul 30, 1999 at 01:08:12AM -0500, Manoj Srivastava wrote:
> Anthony> FWIW, I don't think forcing all packages to have postinst's
> Anthony> and prerm's for the rest of eternity to be a particularly
> Anthony> good solution either.
> You don't need it for the rest of eternity. We
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> Until the (quote: ``future version of policy'' comes out, the
> package in questin (wonko, unless you have forgotten), is in
> violation of the current policy version, (which, in this example,
> happens to be 3.0.0.1). Saying you are stick
Joseph Carter <[EMAIL PROTECTED]> writes:
> I propose that we create a safe migration path between /var/spool/mail and
> /var/mail.
>
> The base-files package should implement the following:
> * If /var/mail does not exist but /var/spool/mail does (standard
> configuration today), a symlink
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> However, the FHS only says that host-specific configuration files
> (like fstab, network configuration, etc) need to live in /etc. In that
> case, why do we mandate that all configuration files live in /etc?
> Some can certainly be shared between hosts
On Fri, Jul 30, 1999 at 01:19:49AM -0700, Daniel Quinlan wrote:
> > I propose that we create a safe migration path between /var/spool/mail and
> > /var/mail.
> >
> > The base-files package should implement the following:
> > * If /var/mail does not exist but /var/spool/mail does (standard
> >
On Thu, Jul 29, 1999 at 10:36:20PM -0500, Manoj Srivastava wrote:
> Then you have not being paying attention to this list. 5
> formal objections shot down a proposal less than a week ago.
Five, yes. This was one - and more of a statement of intent than actual
invoking of the thing.
>
On Thu, 29 Jul 1999, Joseph Carter wrote:
> > > FHS issues should not be bugs in potato---next version maybe, but not
> > > potato, I agree.
> >
> > For this reason we have to be careful in the wording.
>
> No we don't. =p I have no intention of recompiling all of my packages
> for policy 3 be
Hi,
What I would like to see is a package containing a script which does *two*
things:
1. mv /usr/doc/* /usr/share/doc
2. Modify dpkg's internal databases (mainly the .list files in the
directory /var/lib/dpkg/info) so that they are in sync with the
previous changes.
This
a) would make the syst
> I don't know how important this is, but there's a de-facto
> virtual package, ispell-dictionary, in use for quite some
> time by the ispell and i* dictionary packages, but not
> listed in virtual-package-names-list.text
There's a rejected proposal to implement this. See if you can find it
(o
On Fri, Jul 30, 1999 at 01:09:22PM +0200, Santiago Vila wrote:
> > > For this reason we have to be careful in the wording.
> >
> > No we don't. =p I have no intention of recompiling all of my packages
> > for policy 3 before we release potato. Most people don't. (Most of mine
> > have gotten r
On Fri, Jul 30, 1999 at 01:21:32PM +0200, Santiago Vila wrote:
> What I would like to see is a package containing a script which does *two*
> things:
>
> 1. mv /usr/doc/* /usr/share/doc
> 2. Modify dpkg's internal databases (mainly the .list files in the
> directory /var/lib/dpkg/info) so that the
On Fri, 30 Jul 1999, Julian Gilbey wrote:
> > I don't know how important this is, but there's a de-facto
> > virtual package, ispell-dictionary, in use for quite some
> > time by the ispell and i* dictionary packages, but not
> > listed in virtual-package-names-list.text
>
> There's a rejected
On Fri, Jul 30, 1999 at 09:47:22AM +0100, Julian Gilbey wrote:
> There's a rejected proposal to implement this. See if you can find it
> (on http://www.debian.org/Bugs/db/pa/ldebian-policy.html if I remember
> correctly), resurrect it and second it. It'll probably then pass.
http://bugs.debian.o
On Fri, 30 Jul 1999, Joseph Carter wrote:
> On Fri, Jul 30, 1999 at 01:09:22PM +0200, Santiago Vila wrote:
*> > > > For this reason we have to be careful in the wording.
> > >
> > > No we don't. =p I have no intention of recompiling all of my packages
> > > for policy 3 before we release potato
On Fri, 30 Jul 1999, Joseph Carter wrote:
> e) pointless if the package maintainer does not move change the next
>version of the package to use /usr/share/doc
Nothing prevents you from running the script again after upgrading to
potato+1, if there are actually packages with /usr/doc left in p
Hi,
On Fri, Jul 30, 1999 at 04:54:07PM +1000, Anthony Towns wrote:
> Then for woody+1 we let people drop the scripts whenever they feel
> like. Crufty symlinks get removed when everyone updates to a new
> base-files that rm's symlinks from within /usr/doc in its postinst on
> upgrade, or something
On Fri, Jul 30, 1999 at 03:01:46PM +0200, Santiago Vila wrote:
> I *never* talked about severity levels of bugs. You say FHS is not
> release-critical for potato, and I agree, but this does *not* mean that we
> don't have to switch to FHS.
You're right, we do have to switch. Not all at once.
>
On Fri, Jul 30, 1999 at 03:18:13PM +0200, Santiago Vila wrote:
> On Fri, 30 Jul 1999, Joseph Carter wrote:
>
> > e) pointless if the package maintainer does not move change the next
> >version of the package to use /usr/share/doc
>
> Nothing prevents you from running the script again after up
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 already moved to
/usr/share/doc (where some of them left back a
Hi,
>>"Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
Chris> Not an option? You're missing my point again. I've got
Chris> packages installed that are 2.4.0. In many cases, these are
Chris> the latest, up-to-date versions. Ok, my hypothetical
Chris> Mr. A. S. Shole (the name says it a
On Fri, Jul 30, 1999 at 03:53:47PM +0200, Marcus Brinkmann wrote:
> On Fri, Jul 30, 1999 at 04:54:07PM +1000, Anthony Towns wrote:
> > Then for woody+1 we let people drop the scripts whenever they feel
> > like. Crufty symlinks get removed when everyone updates to a new
> > base-files that rm's sym
> On Fri, 30 Jul 1999, Julian Gilbey wrote:
>
> > > I don't know how important this is, but there's a de-facto
> > > virtual package, ispell-dictionary, in use for quite some
> > > time by the ispell and i* dictionary packages, but not
> > > listed in virtual-package-names-list.text
> >
> > Th
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 interest might be sufficient, but we should
Julian> ask Manoj.
Umm
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> [I think, since this is a dead proposal, there is not much
> point carrying out what has become a nit picking discussion
If an attempt is going to be made to get the tech committee to mandate
this proposal over the objections of many
On Fri, Jul 30, 1999 at 04:03:46PM -0700, Chris Waters wrote:
> > Chris> Personally, I still think 1) is the best choice. Potato is going to
> > Chris> be violating the FHS here, I think it's clear, why not just go ahead
> > Chris> and violate it good and hard?
>
> I *still* think this is the
Manoj Srivastava wrote:
>
>... So, if folks agree to this, I would say that we need the
> proposer and seconds (and an explanation) in place before the status
> of the bug is changed. Comments?
I'm the prospective proposer. My first sentence was "I don't know
how important this is..." and
42 matches
Mail list logo
