Re: dpkg-statoverride: Do I need a cluebat?
On Sat, Mar 13, 2004 at 10:45:48PM +0100, Andreas Barth wrote:
> I'm just plaguing myself with dpkg-statoverride, and I have one
> fundamental question: Do I have a silly problem and need a cluebat, or
> is dpkg-statoverride broken by design?
> What I want to do: I have a package that had different stati for one
> directory via dpkg-statoverride. So, I need to force some setting
> under special conditions. However, I don't want to override
> sysadmins settings.
> What I don't understand is, why there are not two levels of
> dpkg-statoverride, one for the maintainer and one for the admin.
> Furthermore, dpkg-statoverride could even read the maintainer
> information from package.statoverride. This would have the advantage
> that there is no need to use constructs like:
> if ! dpkg-statoverride --list /usr/lib/games/nethack/recover >/dev/null
> dpkg-statoverride --add root games 2755 /usr/lib/games/nethack/recover
> but just to put the file in the right place, call a
> dpkg-statoverride --update nethack
> and I'm done. Local admins changes would have automatic precedence,
> but I wouldn't need to care about them (nor about changes of my stati)
> at all.
> Well, why is this not done? Can someone hit me with the cluebat?
More precisely, policy 10.9.1:
Given the above, `dpkg-statoverride' is essentially a tool for system
administrators and would not normally be needed in the maintainer
The following example about how to use it to manage dynamically
allocated group IDs does seem pretty broken though.
MontaVista Software Debian GNU/Linux Developer