On debian-policy, Chris Waters <[EMAIL PROTECTED]> wrote:
>> The EDITOR and VISUAL variables are *NIX traditions, and are
>> already supported by most well-written programs, and even many
>> badly written ones.
Edward Betts <[EMAIL PROTECTED]> writes:
> Talking about the enviroment variables EDITO
On Sat, Jun 05, 1999 at 02:00:42PM -0700, Joey Hess wrote:
> Branden Robinson wrote:
> > If I understood the proposal correctly, bible-kjv and verse would both go
> > into the new data section. "verse" because it's designed to work only with
> > only one data file -- bible-kjv.
>
> That's silly.
Joey Hess wrote:
> Policy still suggests /etc/rc.boot instead of /etc/rcS.d (#32448)
> * Proposed on 26 Jan 1999 by Brian Servis; seconded by Julian
> Gilbey.
> * Change policy to refer to /etc/rcS.d instead of the old
> /etc/rc.boot/
> ( No packages in potato still use /etc/rc.boot
> I have been using /usr/share for some time now in all my packages, including
> ones
> that were in the slink, release.
So?
Here's what's been happening on debian-policy this week.
Thanks to Julian Gilbey, every old proposal on the BTS has been added
to this list. Most of them are marked "old". At least two of them seem
to be consesnsuses already and appear as accepted amendments.
Note: for details of the policy proce
On debian-policy, Chris Waters <[EMAIL PROTECTED]> wrote:
> Making this policy would require modifying a *huge* number of
> programs. The EDITOR and VISUAL variables are *NIX traditions, and
> are already supported by most well-written programs, and even many
> badly written ones.
>
> IOW, we sup
Branden Robinson wrote:
> If I understood the proposal correctly, bible-kjv and verse would both go
> into the new data section. "verse" because it's designed to work only with
> only one data file -- bible-kjv.
That's silly. 'passwd' is a program designed to work with only 1 data file,
I don't t
Edward Betts wrote:
>On policy, Oliver Elphick wrote:
>> verse doesn't use bible-kjv-text for its source, but a compilation of
>> quotes that its original author put together. It is actually a rather
>> small package, with a 38Kb deb, including the verses. It's on a par
>> with, say, f
Edward Betts wrote:
> The solution to that battle is to ask the user.
No it's not. sensible-editor already uses $EDITOR if that is set. There's no
need to ask the user, they would indicate what editor they prefer in the
usual way.
> Debian has a lot of programs that do the same thing. These funct
J.H.M. Dassen wrote:
> One reason that I can think of is that with $EDITOR, a program can look at
> what editor the user wants, and choose command line options on the basis of
> that; that doesn't work with sensible-editor.
Look at sensible-editor:
#!/bin/bash
shopt -s execfail
exec ${VISUAL:-${E
Previously Josip Rodin wrote:
> Note that the previously proposed QA policy includes much wider range
> of NMU power for the security fixes, and nobody has commented negatively
> on it, so...
I haven't seen that so I can't comment on that... this is a sufficient
minimum though though.
Wichert.
-
I have been using /usr/share for some time now in all my packages, including
ones
that were in the slink, release.
On Sat, Jun 05, 1999 at 04:31:31PM -0300, Nicolás Lichtmaier wrote:
>
> Could sbdy explain me why?
>
> Why would I need to share this static data among several machines? This
> mig
Could sbdy explain me why?
Why would I need to share this static data among several machines? This
might mave been a concern when dskspace where a problem... Think that this
breaks the idea of a packaging system too.
And because this breaks the idea of a packaging system (the packaging
system i
Nicolás Lichtmaier <[EMAIL PROTECTED]> writes:
> I think we should extend policy by adding a XEDITOR variable that when
> defined overrides de EDITOR var iff we are in X.
Making this policy would require modifying a *huge* number of
programs. The EDITOR and VISUAL variables are *NIX traditions,
-BEGIN PGP SIGNED MESSAGE-
> On Sat, 5 Jun 1999 02:47:05 +0200, Wichert Akkerman <[EMAIL PROTECTED]>
> said:
Wichert> As some people may have noted we're in the process of
Wichert> creating security.debian.org, which will be a location where
Wichert> security fixes are install
On Sat, Jun 05, 1999 at 02:47:05AM +0200, Wichert Akkerman wrote:
> As some people may have noted we're in the process of creating
> security.debian.org, which will be a location where security
> fixes are installed as fast as possible, without having to
> wait for a daily dinstall and mirror run.
> sensible-editor will behave as needed by the current policy, but is
> more flexible. It could start xemacs on X and zile on console or do
> other additional checks. I think policy should state that programs
> should use sensible-editor as their editor.
I think we should extend policy by adding
On Sat, Jun 05, 1999 at 02:47:05AM +0200, Wichert Akkerman wrote:
>
> As some people may have noted we're in the process of creating
> security.debian.org, which will be a location where security
> fixes are installed as fast as possible, without having to
> wait for a daily dinstall and mirror r
On Fri, Jun 04, 1999 at 06:46:47PM -0400, Fabien Ninoles wrote:
> > The data section would be governed by the following rules:
> > - No package can depend on a package in data.
>
> Can *solely* depends on a package in data. ORed Depends, if
> it's also resolved by a default package in main, is goo
As some people may have noted we're in the process of creating
security.debian.org, which will be a location where security
fixes are installed as fast as possible, without having to
wait for a daily dinstall and mirror run. To make this truely
effective though the security team has to be able to
20 matches
Mail list logo
