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:
>>
>&g
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 hav
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
> subdirect
On Sun, 14 Jan 2018, Santiago Vila wrote:
> The "/usr/local" directory itself and all the subdirectories created
> by the package should have permissions 755 and be owned by "root:root"
> if /etc/staff-group-for-usr-local does not exist, and they should have
> permissions 2775 (group-writable and s
This would be a "pseudo-patch":
Replace this:
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".
by this:
The "/usr/local" directory itself and all the sub
Hello Debian Policy people.
This is to tell you that I've finally changed base-files in unstable
to not create /etc/staff-group-for-usr-local anymore on new installs,
following the TC decision about this in Bug #484841 and the transition
plan explained in the file /etc/staff-group-for-usr-local it
Thomas Hochstein writes:
> Santiago Vila wrote:
>> 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 w
Santiago Vila wrote:
> 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 th
Santiago Vila writes:
> 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
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-writea
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 doc
11 matches
Mail list logo
