Marc Haber <[EMAIL PROTECTED]> writes:
> On Tue, Nov 14, 2006 at 06:12:24PM -0800, Russ Allbery wrote:
>> Steve Langasek <[EMAIL PROTECTED]> writes:
>>> In the case of adduser, there is a strong case for not doing deluser at
>>> *all* on purge, because it's impossible to ensure that there are no
>
Zack Weinberg <[EMAIL PROTECTED]> writes:
> I'd like to see this say something about what may be assumed of the
> standard shell utilities, as well as the shell itself, and in
> particular I'd like to see coreutils bug #339085 addressed [please see
> the bug log for my personal very strong opinion
On Tue, Nov 14, 2006 at 10:01:16PM -0800, Don Armstrong wrote:
> On Tue, 14 Nov 2006, Russ Allbery wrote:
> > This is something that I'd really like to see us sort out in policy,
> > since I think we should be able to describe consistent behavior with
> > regard to system users and package purging
On Tue, Nov 14, 2006 at 06:12:24PM -0800, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > In the case of adduser, there is a strong case for not doing deluser at
> > *all* on purge, because it's impossible to ensure that there are no
> > off-line or remote resources referencing
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Heck, I'm entirely happy with Manoj's suggestion to drop the whole damn
> thing, and simply say "/bin/sh will be bash."
Well, I'm not, and neither are a lot of other people judging from this
discussion.
> No. I'm saying that the existing noticed
On Tue, 2006-11-14 at 22:15 -0800, Russ Allbery wrote:
> The problem sparking this thread and my initial work on a Policy patch is
> not a problem caused by shells with builtins; it is, in fact, not a
> technical problem at all in the sense that no user has had their system
> broken by the use of
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> On Tue, 2006-11-14 at 18:59 -0800, Russ Allbery wrote:
>> I think this would be a great deal of work for little useful benefit.
> Why? Surely it would be useful to know what the differences are between
> various shells.
I believe that such a doc
On Tue, 14 Nov 2006, Russ Allbery wrote:
> This is something that I'd really like to see us sort out in policy,
> since I think we should be able to describe consistent behavior with
> regard to system users and package purging to our users.
What makes the most sense to me is to not delete the use
On Tue, 2006-11-14 at 18:59 -0800, Russ Allbery wrote:
> I think this would be a great deal of work for little useful benefit.
Why? Surely it would be useful to know what the differences are between
various shells. The statement "Posix-compatible" was apparently
intended by the authors of that p
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Nov 14, 2006 at 06:12:24PM -0800, Russ Allbery wrote:
>> This is something that I'd really like to see us sort out in policy,
>> since I think we should be able to describe consistent behavior with
>> regard to system users and package purging t
On Tue, Nov 14, 2006 at 06:12:24PM -0800, Russ Allbery wrote:
> >> Hmm, I would read policy in a way that since a package can not rely on
> >> its dependencies being present during purge, their pure absence alone
> >> should not be a valid reason to fail. If this on the other hand is a
> >> valid e
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> On Tue, 2006-11-14 at 18:38 -0800, Russ Allbery wrote:
>> I think there are obvious reasons to exempt shell builtins from this
>> requirement, so you're going to have to present more of an argument
>> than this. I think this is a very strained rea
On Tue, 2006-11-14 at 18:38 -0800, Russ Allbery wrote:
> > "Two different packages must not install programs with different
> > functionality but with the same filenames."
>
> > There does not seem to be any reason to exempt shell builtins from this
> > requirement.
>
> I think there are obvious
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> I do. Debian test is provided by the coreutils package. As the man
> page says:
>( EXPRESSION )
> EXPRESSION is true
> And, we have the existing rule in section 10.1 of the policy manual:
> "Two different packages must not in
> Not in my experience, but I haven't tested for them in particular. On my
> system, I see one maintainer script using test -o, none using test -a, and
> none using test ().
>
> I currently see no need to require that test () be supported.
I do. Debian test is provided by the coreutils package
Steve Langasek <[EMAIL PROTECTED]> writes:
> On Tue, Nov 14, 2006 at 09:35:12PM +0100, Frank Lichtenheld wrote:
>> Hmm, I would read policy in a way that since a package can not rely on
>> its dependencies being present during purge, their pure absence alone
>> should not be a valid reason to fail
On Wed, 2006-11-15 at 02:20 +0100, David Weinehall wrote:
> > and failed
> > miserably.
>
> And you belong to the group of people that caused it to fail...
I refused to stop using test -a in my packages as well, and refused to
declare #!/bin/bash.
Here's why.
test -a is not a "bashism".
It's a
David Weinehall <[EMAIL PROTECTED]> writes:
> On Tue, Nov 14, 2006 at 08:03:54PM +0100, Marco d'Itri wrote:
>> No, there is no such issue. The issue is that a few people tried to
>> remove all use of test -a/-e and local from /bin/sh scripts,
> I admit belonging to the group of some people here.
David Weinehall <[EMAIL PROTECTED]> writes:
> On Fri, Nov 10, 2006 at 12:01:10AM -0600, Manoj Srivastava wrote:
>> Secondly, why should we explicity carve out an exception for
>> test -a and -o, rather than saying that the XSI extensions need be
>> supported? The X/Open System Interface
On Fri, Nov 10, 2006 at 12:01:10AM -0600, Manoj Srivastava wrote:
> Hi,
>
> Firstly, should we be pointing to the SuS instead of POSIX
> (there is work going on a new version of the SUS), since it is open,
> and readily available on th 'net, and people can readily see it (as
> opposed t
On Tue, Nov 14, 2006 at 12:36:04PM -0600, Manoj Srivastava wrote:
[snip]
> So, what features do we settle on? we can either standardize
> on, well, a standard: POSIX/SUSv3, -- but there are things we use
> that come from XSI. I guess we could standardize on SUSv3 +XSI
> shells. Would st
On Tue, Nov 14, 2006 at 08:03:54PM +0100, Marco d'Itri wrote:
> On Nov 14, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>
> > So, what features do we settle on? we can either standardize
> > on, well, a standard: POSIX/SUSv3, -- but there are things we use
> > that come from XSI. I guess
On Nov 14, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> So, what features do we settle on? we can either standardize
> on, well, a standard: POSIX/SUSv3, -- but there are things we use
> that come from XSI. I guess we could standardize on SUSv3 +XSI
> shells. Would still make local il
On Mon, 13 Nov 2006 17:31:32 +0100, Stefano Zacchiroli <[EMAIL PROTECTED]>
said:
> On dom, 2006-11-12 at 14:02 -0600, Manoj Srivastava wrote:
>> I suggest that we specify tow headers: and SCM specific header,
>> XS-Vcs- where name is one keyword from a specified list (bzr,
>> cvs, svn, darcs, gi
On Sat, 11 Nov 2006 23:10:52 -0600, Manoj Srivastava
<[EMAIL PROTECTED]> said:
> OK. How about we again step back, and examine the rationale
> behind this, and the use cases that we intended to support? Look,
> bash is essential, and ships as /bin/sh; nothing is required as far
> as s
25 matches
Mail list logo
