Hi Lars, On Tue, Apr 12, 2011 at 06:41:10PM +0100, Lars Wirzenius wrote: > > But shouldn't we say they _must_ lock package-specific system users > > and groups when the package is removed ? > > I think that's a good idea. Steve Langasek in the bug (#621833) and > others agree, so I think there's a strong consensus on that.
I don't think I'd agree there, at least without also addressing: * It also needs to limit the scope to locally defined users (i.e. not fail when it is unable to lock an NIS/LDAP/etc account). * There needs to be a way to explicitly do that with adduser or a similar tool[1][2][3][4]. Also, we haven't discussed what should be done in the case of a user account possibly shared between different packages, where any one of them may create it and 1..N of them might be installed. For example, nagios/nrpe comes to mind, or maybe parallel installed postgres versions and related tools. Alternatively, if we strictly interpret what Ian suggested to not include such packages, we should state that and/or give alternate instructions for this case. I second your original proposal though, that packages must not delete system users that they have created. I don't think anyone had objections to that, and the question is whether things should be taken further. sean [1] Assuming it must be done with one tool, it should also state "lock users with $thiscommand $theseoptions", and depend on "$thisversion" of the tool in question if the tool needs to be updated. [2] And if "$theseoptions" are not specifically for the "local only case", we need a way to tell the difference between a "locking failed" error and a "user is remote" error. [3] Or maybe instead of using a tool we have something like declarative users, where we state policy and farm it off to dpkg to implement? [4] Whoa, footnotespam ftw, sorry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org