Bug#299007: Transitioning perms of /usr/local

[Russ Allbery]

Adding the bug instead of debian-policy@.

Ian Jackson  writes:
> Don Armstrong writes ("Re: Bug#299007: Transitioning perms of /usr/local"):

>> Thanks for doing this work! The original wording took me a few readings
>> to parse; I suggest this instead:
>> 
>>  If /etc/staff-group-for-usr-local does not exist, /usr/local and all
>>  subdirectories created by packages should have permissions 0755 and be
>>  owned by "root:root". If /etc/staff-group-for-usr-local exists,
>>  /usr/local and subdirectories should have permissions 2775
>>  (group-writable and set-group-id) and be owned by "root:staff".

> SGTM.  (AKA "seconded".)

Seconded.

Thank you for bringing this back to life, Santiago!  I've been wanting to
resolve this for some time.

-- 
Russ Allbery (r...@debian.org)   

Bug#299007: Transitioning perms of /usr/local

[Ian Jackson]

Santiago Vila writes ("Bug#299007: Transitioning perms of /usr/local"):
> [ I, for one, would prefer to reunificate with Ubuntu in this issue
>   and get rid of staff completely, but this is just my opinion ]
> 
> Should we maybe ask TC again about this? A lot of time have elapsed
> since they made their decision, and the world has changed a lot since
> then.

None of the reasons why I like to use the group staff the way I do
have changed.  See
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484841#62

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#299007: Transitioning perms of /usr/local

[Ian Jackson]

Don Armstrong writes ("Re: Bug#299007: Transitioning perms of /usr/local"):
> Thanks for doing this work! The original wording took me a few readings
> to parse; I suggest this instead:
> 
>  If /etc/staff-group-for-usr-local does not exist, /usr/local and all
>  subdirectories created by packages should have permissions 0755 and be
>  owned by "root:root". If /etc/staff-group-for-usr-local exists,
>  /usr/local and subdirectories should have permissions 2775
>  (group-writable and set-group-id) and be owned by "root:staff".

SGTM.  (AKA "seconded".)

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#880920: Document Rules-Requires-Root field

[Ian Jackson]

Josh Triplett writes ("Bug#880920: Document Rules-Requires-Root field"):
> On Fri, 29 Dec 2017 11:29:00 + Niels Thykier  wrote:
> > +  # Command "sudo", with arguments "-nE" and "--"
> > +  export DPKG_GAIN_ROOT_CMD='sudo -nE --'
> > +  # Command "fakeroot" with the single argument "--"
> > +  export DPKG_GAIN_ROOT_CMD='fakeroot --'
> 
> You use sudo with -E here to preserve the environment. If that's a
> requirement, then the preceding paragraph should explicitly say
> something like "the command must preserve all environment variables,
> unmodified".

I think the environment does need to be preserved, indeed.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bug#886219: lintian should be less pedantic about latest policy version

[Ian Jackson]

Sean Whitton writes ("Re: Bug#886219: lintian should be less pedantic about 
latest policy version"):
> Let me first say exactly what change I'd recommend:
> - out-of-date-standards-version should be I: or P: instead of W:
> - ancient-standards-version should remain W:
> - ancient-standards-version should be triggered when S-V contains a
>   release of Policy from the previous stable release cycle
...
> You argue that
> - whenever a maintainer uploads a package and S-V is out-of-date, they
>   should work through the relevant entries in the Policy Manual's
>   Upgrading Checklist
> - Policy Manual releases should be infrequent to avoid maintainers
>   having to do this too often
> 
> On the contrary, I argue that
> - the only thing that should be /required/ when uploading a package is
>   making the package non-trivially better than the current version in
>   unstable
> - updating S-V should never block uploading other improvements
> - there are good reasons to release the Policy Manual frequently, and
>   this should not be blocked by the expectation that everyone respond to
>   those new versions in their very next uploads.

Thank you, Sean, for arguing this so much better than I am doing.

> Also relevant here is Enrico's talk at DebConf17,[1] where he cautioned
> against manipulating volunteers into doing work.  Requiring prerequisite
> work that is not necessary for co-ordinating with other volunteers might
> well fall into that category.
> 
> [1] https://debconf17.debconf.org/talks/92/

I clearly must watch this talk.

Ian.