On Mon, 31 May 1999, Julian Gilbey wrote:
> > At 14:48 +0100 1999-05-30, Julian Gilbey wrote:
> > >I second this, and propose that the section should be reworded as
> > >follows:
> > >
> > >3.3.4. Boot-time initialisation
> > >---
> > >
> > > There used to be anothe
> On Sun, 30 May 1999, Julian Gilbey wrote:
>
> > I checked through the current version of policy, and FSSTND is
> > mentioned in several places. They all appear to be trivially
> > replaceable by the corresponding references to the FHS. [...]
>
> Maybe this is not as easy as it seems at first.
Santiago Vila wrote:
> Well, what I would like to see is a general policy about bugs, covering
> all aspects of bug reporting, forwarding, severitying and closing. Who is
> allowed to do that, and when. For example, how many times are a submitter
> allowed to reopen a bug (I would say that only onc
Brock Rozen wrote:
> Does this mean that the "proposal-submitting guidelines" will not become
> part of the policy itself? I think that should be done, as it makes them
> official and allow for them to be changed officially as policy would
> dictate (fine, it would dictate itself how it would chang
>>
>> This would take away the admins ability to make modifications to the
>> scripts.
>> I would find this to be a bad thing.
>
> Maybe the wording's slightly wrong then. Maybe I should say
> "locally-modified scripts" rather than "user-modified scripts"?
>
> I mean files such as /etc/init.d/
Marcus Brinkmann wrote:
> I already granted you this point. However, my /usr/X11R6 contains 45 MB of
> data. What is the upper limit? Do people really live on such dangerous
> edges that they can move 50 MB across partitions without repartitioning?
I have over 225 mb in there.
Now 120 MB of that
On policy, Santiago Vila <[EMAIL PROTECTED]> wrote:
> Among other things: Old awk is not guaranteed to have user-defined
> functions (if I'm not mistaken).
>
> However, I have yet to see an awk packaged for Debian
> which is not a new awk.
original-awk ?
--
I consume, therefore I am
On policy, Santiago Vila <[EMAIL PROTECTED]> wrote:
> > Yes, I see what you are saying, but why should we worry about tweaking
> > upstream software in various packages (and who knows which they'll end
> > up being?) to use "awk" instead of "nawk" when we can simply provide a
> > nawk -> awk symlin
On policy, Julian Gilbey <[EMAIL PROTECTED]> wrote:
> > What about the ordering in /etc/rc?.d is it important, should we not be
> > restarting stuff out of order?
>
> I would guess not; these are not facilities being restarted but newly
> installed ones. If there is a desperate problem with this,
Hi,
On Sun, May 30, 1999 at 10:24:38PM -0400, Alex Yukhimets wrote:
> > How so?
>
> Branden knows better. And he is already encouraged to overcome all of them :0
>
> > Oh come on. We change the pathes of almost any upstream packaging every day.
>
> Well, from /usr/local to /usr - I am cool with
Julian Gilbey wrote:
> Now that we have a "fixed" priority in the developers-reference (this
> is not in policy itself), can this proposal be closed?
Your quote is not sufficient for me to decide.
Regards,
Joey
--
Unix is user friendly ... It's just picky about its friends.
Please al
Your message dated Mon, 31 May 1999 18:17:27 +0200 (CET)
with message-id <[EMAIL PROTECTED]>
and subject line Closing this bug (/etc/aliases not being there, etc. etc).
has caused the attached bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this
On Mon, 31 May 1999, Julian Gilbey wrote:
> Now that we have a "fixed" priority in the developers-reference (this
> is not in policy itself), can this proposal be closed?
Well, what I would like to see is a general policy about bugs, covering
all aspects of bug reporting, forwarding, severitying
On Sun, 30 May 1999, Julian Gilbey wrote:
> > Santiago Vila <[EMAIL PROTECTED]> wrote:
> > > If not, should we clearly write in policy that hardlinks to conffiles
> > > should be avoided wherever possible?
>
> Please could someone enlighten me about this proposal?
Some time ago I discovered how
On Mon, 31 May 1999, Julian Gilbey wrote:
> Santiago Vila wrote:
> > However, since every awk in the system is always a new awk and it is
> > always available as awk, we could standarise the expectations and declare
> > that every time a program in a Debian system needs any awk (either old or
> >
On Sun, 30 May 1999 at 13:25, Joey Hess wrote about "Re: Making sure that...":
> > Another important question: what about those who object to the proposal?
> > Should they be formally recorded? And what happens with that? Should we
> > require X number more seconders than objectors? (X should be t
On Mon, 31 May 1999 at 14:47, Santiago Vila wrote about "Bug#38612:...":
> > Package: debian-policy
> > Version: 2.5.0.0
> > Severity: wishlist
> >
> > It would make a lot of sense if Manoj's proposal-submitting guidelines
> > were to be placed in the debian-policy package and referred to by the
On Mon, May 31, 1999 at 12:29:46AM +0100, Julian Gilbey wrote:
> It would make a lot of sense if Manoj's proposal-submitting guidelines
> were to be placed in the debian-policy package and referred to by the
> policy (section 1.3).
I second this.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED]
At 19:27 +0100 1999-05-30, Julian Gilbey wrote:
20099 No policy on /etc/environment
[Should we have one? A policy on it or even should we have it?]
Status: Proposal
We have several programs that use it, the problem is that there are
at least two different expected formats. I'd sa
Julian Gilbey wrote:
> > >In other words, is it OK to announce the move to FHS on
> > >-devel-announce so that developers can start making the necessary
> > >changes to their packages?
> > We should wait for FHS 2.1, some of the changes in 2.0 like /var/state
> > will be removed.
>
> My feeling
Processing commands for [EMAIL PROTECTED]:
> retitle 26995 [BUG] problem viewing fsstnd-1.2.dvi.gz
Bug#26995: [PROPOSED] fsstnd-1.2.dvi.gz is wrong.
Changed bug title.
> severity 26995 normal
Bug#26995: [BUG] problem viewing fsstnd-1.2.dvi.gz
Severity set to `normal'.
> thanks
Stopping processin
On Mon, 31 May 1999, Julian Gilbey wrote:
> Package: debian-policy
> Version: 2.5.0.0
> Severity: wishlist
>
> It would make a lot of sense if Manoj's proposal-submitting guidelines
> were to be placed in the debian-policy package and referred to by the
> policy (section 1.3). (And the guideline
On Sun, 30 May 1999, Julian Gilbey wrote:
> I checked through the current version of policy, and FSSTND is
> mentioned in several places. They all appear to be trivially
> replaceable by the corresponding references to the FHS. [...]
Maybe this is not as easy as it seems at first. For example, w
> > > > Does anyone expect there to be a nawk program? If so, this suggestion
> > > > is moot. If not, we can probably just do away with it.
> > >
> > > Debian currently has five nawk scripts:
> > > [...]
> > > I see no reason to refrain from keeping the nawk link around.
> > > I also don't thin
> >In other words, is it OK to announce the move to FHS on
> >-devel-announce so that developers can start making the necessary
> >changes to their packages?
> We should wait for FHS 2.1, some of the changes in 2.0 like /var/state
> will be removed.
Surely we could announce it with a notice say
Previously Julian Gilbey wrote:
> Which is my question: the amendment has been accepted; can we go ahead
> as if it were policy or should we wait until it's actually
> incorporated?
Definitely wait until it's incorporated.
Wichert.
--
> At 14:48 +0100 1999-05-30, Julian Gilbey wrote:
> >I second this, and propose that the section should be reworded as
> >follows:
> >
> >3.3.4. Boot-time initialisation
> >---
> >
> > There used to be another directory, `/etc/rc.boot', which
> > contained script
> On 30-May-99 Julian Gilbey wrote:
> > retitle 21585 [PROPOSED] /etc/init.d/
On May 30, Julian Gilbey <[EMAIL PROTECTED]> wrote:
>In other words, is it OK to announce the move to FHS on
>-devel-announce so that developers can start making the necessary
>changes to their packages?
We should wait for FHS 2.1, some of the changes in 2.0 like /var/state
will be removed.
-
Torsten Landschoff <[EMAIL PROTECTED]> writes:
>...
> While I like to overall idea there are some problems with your proposal. This
> utility you suggested would work just fine but it has a few issues for future
> extensions. For example I dream of a Debian installation which asks the
> configure
On Sun, 30 May 1999, Julian Gilbey wrote:
> > Julian Gilbey wrote:
> > > Does anyone expect there to be a nawk program? If so, this suggestion
> > > is moot. If not, we can probably just do away with it.
> >
> > Debian currently has five nawk scripts:
> >
> > /usr/sbin/mk-accessdb and /usr/sbi
On Sun, 30 May 1999, Julian Gilbey wrote:
> > I do not withdraw the bug: If every awk in the system is already a "new
> > awk", why do we need /usr/bin/nawk at all?, we could use always
> > /usr/bin/awk and it would always work.
> >
> > Is there a rationale somewhere?
> >
> > Maybe we should che
Now that we have a "fixed" priority in the developers-reference (this
is not in policy itself), can this proposal be closed?
Julian
> Package: debian-policy
> Version: 7 Apr 1998 18:59:29 +0100
>
> I think this needs clarification. There is a problem with non-active
> maintainers or maintai
At 14:48 +0100 1999-05-30, Julian Gilbey wrote:
I second this, and propose that the section should be reworded as
follows:
3.3.4. Boot-time initialisation
---
There used to be another directory, `/etc/rc.boot', which
contained scripts which were run once per
On 30-May-99 Julian Gilbey wrote:
> retitle 21585 [PROPOSED] /etc/init.d/
> How so?
Branden knows better. And he is already encouraged to overcome all of them :0
> Oh come on. We change the pathes of almost any upstream packaging every day.
Well, from /usr/local to /usr - I am cool with that.
> >, requiring change in a partition scheme of MANY
> > existing systems,
>
> > Yes, difficult. And unnecessary, and useless, and inconvenient, and
> > destroying
> > standards and traditions, requiring change in a partition scheme of MANY
> > existing systems, not-easily-extendible to another window system which may
> > come, overcrowding already OVERcrowded /usr/bin, et
On Sun, May 30, 1999 at 09:01:19PM -0400, Alex Yukhimets wrote:
> Yes, difficult. And unnecessary, and useless, and inconvenient, and destroying
> standards and traditions, requiring change in a partition scheme of MANY
> existing systems, not-easily-extendible to another window system which may
>
On Sun, May 30, 1999 at 09:01:19PM -0400, Alex Yukhimets wrote:
>
> Yes, difficult.
How so?
> And unnecessary, and useless, and inconvenient, and
> destroying standards and traditions
Oh come on. We change the pathes of almost any upstream packaging every day.
>, requiring change in a partitio
> > Therefore,
> > /usr/bin/X11 would be a symlink to /usr/bin (X11 -> .)
> > /usr/include/X11 would become a regular directory
> > /usr/lib/X11 would become a regular directory
>
> Would the move be difficult?
Yes, difficult. And unnecessary, and useless, and inconvenient, and destroying
s
> On policy, Piotr Roszatycki <[EMAIL PROTECTED]> wrote:
> > > (That is, we should check whether /etc/rcN.d/{S,K}??script exists
> > > where N is the current runlevel and start or stop the script
> > > appropriately if it does -- see the rest of this bugreport for
> > > details.)
> > >
> > > I sec
> On debian-policy, Julian Gilbey <[EMAIL PROTECTED]> wrote:
> > What is the status of accepted policy amendments which have not yet
> > been incorporated into policy?
> >
> > In other words, is it OK to announce the move to FHS on
> > -devel-announce so that developers can start making the necess
42 matches
Mail list logo
