Bug#484333: assigning to tech ctte (Re: status of this bug)

2008-06-06 Thread Robert Millan
On Thu, Jun 05, 2008 at 09:25:24AM -0700, Don Armstrong wrote:
 the
 problem which you are describing is a general one that applies to all
 things which were dependencies which have been downgraded to
 recommends.

You're describing the problem as if it had a property it doesn't have,
which would make it general, and following that, asserting I'm describing
a general problem, which I'm not.

The problem with bash-completion is that it has *never* been a dependency
of bash;  it was split off without the intermediate state of being a
dependency -- and I'm sure you'll agree that this intermediate state is
existing practice (but if you don't, I can find examples).

Once it has been a dependency of bash during the etch-lenny upgrade, I'm
completely fine with it being downgraded to Recommends, or even Suggests.

  My concern is simply that no transition path has been contemplated.
 
 We've explained the transition path; it's upgrading while following
 the release notes.

Given that no resolution has been issued yet, there's no explaining the.
Use proposing a if you like, or anything that isn't misleading.

Anyway, I don't agree that adding instructions about this in the Release
Notes makes the problem disappear for everyone.

In fact, I believe in this situation it's not very useful, because the kind of
user who carefuly reads the Release Notes before an upgrade is also the kind
of user who wouldn't have any trouble figuring out why TAB completion stopped
working.

  As a result the burden of figuring out why hitting TAB misteriusly
  stopped working is put on the majority of users,
 
 The majority of users should be capable of reading the release notes.

You're asserting something that is most likely true, but also irrelevant.
It doesn't matter that Joe user is perfectly capable of reading the Release
Notes if he doesn't actually read them.

If you were to assert the majority of users carefuly read the Release Notes,
would you have any evidence to sustain that?

 There's a reason why we spend the effort writing them.

It is laudable that you spend effort writing the Release Notes, and I
appreciate your effort.  But this doesn't directly archieve the goal that
all users follow all the instructions in them.

 A failure on
 the part of users to read documentation isn't an excuse for crippling
 a system, especially when the negative side effects of failing to read
 the documentation are minor.

What you call crippling has been existing practice for ages.  We're in the
process of redefining that, and honestly I don't see what's the hurry about it.

Are you seriously so concerned about those extra 216 kiB in the base install
that you consider your system crippled because they can't be removed yet?

If you look at the dictionary definition of crippled, you'll see that
missing functionality is much closer to a match.

  Looks fine to me, but please clone instead of reassigning.
 
 If we decide that it should be handled in the release notes, that's
 where the bug goes.

Who is we?  I just checked the list in 
http://www.debian.org/intro/organization
and you don't appear to be a member of the Tech Ctte.

Did I understand wrong, and should the list be updated?

 This is not a bug in bash, but a problem stemming
 from apt not following policy.

This is basicaly true, but then if you consider apt to be the real problem,
it's a problem we can't solve untill lenny is released.

Which brings us back to how do we solve the problem at hand: bash handling
transitions as if apt were following policy, which it isn't yet.

 Here's a suggested resolution for a CTTE member to adopt and vote upon
 to resolve this issue:

I suppose this answers my earlier question.  Well, if you're not a member of
the Tech Ctte, please don't speak as if you were.

Seeing that suggested resolutions are possibly helpful, I thought I could do
the same.  Here's a suggested resolution for a Tech Ctte member to consider
adoption (please excuse me for grammar/spelling mistakes, if any):

--

Acknowledging that:

(1) The lack of Recommends handling in apt has been a long-standing problem
within Debian, and that it has been existing practice to use Depends to
handle transitions when splitting a package, before the package relationship
could be lowered to a Recommends.

(2) Although the problem is solved in the lenny version of apt, the etch
version is still affected.

(3) The Release Notes maintainers may (at their discretion) adopt verbiage
recommending that aptitude be used (or apt be upgraded) when upgrading from
etch to lenny.

(4) Although reading and carefuly following all the instructions in the
Release Notes is the recommended practice, it is likely that a significant
portion of users (and moreso, those affected by this problem) will only
make a partial overview, and therefore is not safe to assume every user
will follow all instructions.

(5) The functionality currently provided by the bash-completion package is
present in the default 

Bug#484333: assigning to tech ctte (Re: status of this bug)

2008-06-06 Thread Don Armstrong
On Fri, 06 Jun 2008, Robert Millan wrote:
 On Thu, Jun 05, 2008 at 09:25:24AM -0700, Don Armstrong wrote:
  the problem which you are describing is a general one that applies
  to all things which were dependencies which have been downgraded
  to recommends.

 The problem with bash-completion is that it has *never* been a
 dependency of bash; 

The presence of a portion of the functionality within the package
creates a de facto dependency; thus, it's a general issue.

[..]

 Who is we? 

I mean we as in Debian, not we as in the tech ctte.
 

In any event, I believe I have made my position on this issue
abundantly clear, as have you. It remains to the tech ctte to jump in,
adopt resolutions and/or decide one way or the other.


Don Armstrong

-- 
If you find it impossible to believe that the universe didn't have a
creator, why don't you find it impossible that your creator didn't
have one either?
 -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556cid=13970629

http://www.donarmstrong.com  http://rzlab.ucr.edu



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#484841: Should /usr/local be writable by group staff?

2008-06-06 Thread Russ Allbery
Package: tech-ctte
Severity: normal

This is a delegation of the resolution of Bug#299007 to the Technical
Committee under points 1 and 3 of section 6.1 of the Constitution.  As
Policy delegate, I am not comfortable making a final decision either
way on this bug and ask that the tech-ctte please make a binding
decision.

The dispute is over the following text in Debian Policy:

 The `/usr/local' directory itself and all the subdirectories created
 by the package should (by default) have permissions 2775
 (group-writable and set-group-id) and be owned by `root.staff'.

The proposed change is to state instead that the /usr/local directory
itself and all the subdirectories created by the package should (by
default) have permissions 755 and be owned by root:root.

The contention in this proposal is that the current Policy-mandated
behavior represents a potential security vulnerability since it allows
elevation of a compromise of group staff to a root compromise since
/usr/local/bin is in root's default path.  The counter-contention is that
the staff group is empty by default and it is up to the local system
administrator to extend that privilege in a way consistent with the local
site security policy.

https://launchpad.net/bugs/13795 is the corresponding Ubuntu bug.
According to that bug log, Ubuntu has chosen to diverge from Debian on
this point.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]