Bug#948115: Revise init script Policy based on GR result

2020-01-04 Thread Sam Hartman
Russ said off-list he was ready for seconds. I second his patch with the status being encouraged rather than recommended change. In seconding, my primary review criteria was whether I thought the change accurately reflected what the GR conclusion was. --Sam signature.asc Description: PGP signat

Bug#944920: Revise terminology used to specify requirements

2020-01-04 Thread Russ Allbery
Sam Hartman writes: > One question: > +The Release Team may, at their discretion, downgrade a Policy requirement > +to a Policy recommendation for a given release of the Debian distribution. > +This may be done for only a specific package or for the archive as a > +whole. This provision is inten

Bug#948115: Revise init script Policy based on GR result

2020-01-04 Thread Russ Allbery
Sam Hartman writes: > I've reviewed your patch. > It looks good. > One minor suggestion: > +The ``start``, ``stop``, ``restart``, and ``force-reload`` options should > +be supported by all init scripts. Supporting ``status`` is recommended but > +not required. The ``reload`` and ``try-restart``

Re: Guidance on solving the username namespacing problem

2020-01-04 Thread Russ Allbery
Philipp Kern writes: > OpenBSD rather successfully standardized on the underscore prefix to > eliminate this conflict altogether. I would like that we recommend the > same thing. I agree. > The main question that has been raised was how to manage the migration. I agree with this too. I'm happ

Re: Guidance on solving the username namespacing problem

2020-01-04 Thread Simon McVittie
On Sat, 04 Jan 2020 at 13:52:51 +0100, Philipp Kern wrote: > now that we are talking again about standardizing user creation using > sysusers, I wonder if you could give me any guidance on how to attack > the Debian system user namespacing problem. It's a good reminder, but I think the naming conv

Re: Guidance on solving the username namespacing problem

2020-01-04 Thread Sam Hartman
> "Philipp" == Philipp Kern writes: Philipp> I tried to raise this issue in [2] a year ago, but I think I don't know Philipp> how to even start drafting a policy snippet about this. Would it be Philipp> sufficient to just mandate "In order to avoid collisions with accounts P

Bug#948115: Revise init script Policy based on GR result

2020-01-04 Thread Sam Hartman
I've reviewed your patch. It looks good. One minor suggestion: +The ``start``, ``stop``, ``restart``, and ``force-reload`` options should +be supported by all init scripts. Supporting ``status`` is recommended but +not required. The ``reload`` and ``try-restart`` options are optional. How about

Bug#944920: Revise terminology used to specify requirements

2020-01-04 Thread Sam Hartman
Russ, I've reviewed your new patch. I haven't been participating in this discussion before, but I think it is fair to say that I have significant experience with these sorts of normative language discussions and Debian policy in general. I agree with all your changes (with one question below). My

Re: Guidance on solving the username namespacing problem

2020-01-04 Thread Philipp Kern
(And then my broken keyboard driver caused this to be sent prematurely. But alas, it's out now.) On 1/4/2020 1:52 PM, Philipp Kern wrote: > [Please cc me on replies as I am not currently subscribed to the list.] > > now that we are talking again about standardizing user creation using > sysusers,

Guidance on solving the username namespacing problem

2020-01-04 Thread Philipp Kern
[Please cc me on replies as I am not currently subscribed to the list.] Hi, now that we are talking again about standardizing user creation using sysusers, I wonder if you could give me any guidance on how to attack the Debian system user namespacing problem. There are some well-known usernames