Bug#299007: Transitioning perms of /usr/local

[Santiago Vila <sanvila@unex.es>]

On Sun, Aug 06, 2017 at 08:03:23AM -0700, Sean Whitton wrote:
> control: retitle -1 Transitioning perms of /usr/local
> 
> Hello Santiago,
> 
> The TC decision in #484841 is not yet reflected in Policy.
> 
> We could close the bug by simply dropping the requirement that
> /usr/local be group-writeable by staff, but Russ says that you would
> like your transition plan to be documented in Policy.  Is this still
> true?  Would you be able to propose a patch against the Policy git repo
> as it currently stands?

I had some items in my todo list regarding this bug and I have to say
I'm really sorry for not doing them. What I had in mind was:

* Ensure that packages conform to the transition plan.
* Submit bugs against packages that do not.
* Contact Niels in case some debhelper change was required for this.

However:

I wonder if we really want to do all that in 2017. The staff-writable
/usr/local for a "sysadmin assistant" was an interesting idea twenty
years ago. Today, we would give a sysadmin assistant an entire
virtual machine to play with, and would probably not bother with this.

So my question would be: Do we really need to support both ways
to handle /usr/local at this point?

And for practical purposes: Will packages really stop fiddling with
/usr/local once I remove /etc/staff-group-for-usr-local in buster
initial install? I have been hesitant of doing this move because
I never took the time to recollect data that would tell me whether
or not it would work.

Thanks.