Re: dpkg-statoverride: Do I need a cluebat?
Andreas Barth <aba@not.so.argh.org> 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?
Yes, probably both, but see below.
> 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.
[...]
That is exactly the problem with dpkg-statoverride.
Rules of thumb:
* Do not modify overrides in maintainerscripts, ship the permissions
in the deb.
* dpkg-statoverride is for the sysadmin.
* Only "if ! dpkg-statoverride --list ..." is completely ok.
Problems arise if you cannot ship the permissions in the deb,
basically you have some options, depending on the requirenents
* Add a dpkg-statoverride.
* Don't ship empty directory in deb, use mkdir.
* re-set permissions/owner in on ever installation in postinst.
if ! dpkg-statoverride --list /file/foo
#ask for suid with debconf
chmod u+s /file/foo
fi
The latter cannot be used often (especially not for chown for
dynamically allocated UIDs), because usually the package would be
completely broken while upgrading until postinst is run.
dpkgV2 is supposed to include support for shipping files owned by
dynamically allocated UIDs in the deb minimizing the need for
dpkg-statoverride but we won't be able to use that until sarge+2 even
if it was implemented 6 months from now.
cu andreas
--
NMUs aren't an insult, they're not an attack, and they're
not something to avoid or be ashamed of.
Anthony Towns in 2004-02 on debian-devel
Reply to: