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.
