On Tue, Mar 02, 2010 at 12:00:25PM +0100, Dominik George wrote:
>
> On Tue, 2 Mar 2010 12:37:25 +0200, Peter Pentchev <roam@ringlet.net>
> wrote:
> > On Sat, Feb 27, 2010 at 12:23:25AM +0100, Cyril Brulebois wrote:
> >> Dominik George <dev@naturalnik.de> (26/02/2010):
> >> > OK, as it is done in postinst, there does not seem to be a
> >> > difference to my current chown setup. dpkg-statoverride will make
> >> > sure that the permissions are set everytiem the file is
> >> > re-installed, but chown in postinst will as well ...
> >>
> >> And will nuke possible local changes?
> >
> > Erm, surely the script would check with dpkg-statoverride --list
> > before setting the permissions, as described in Policy 10.9.1 :)
>
> It is my very *intention* to kick local changes.
Mmm, in this case by "local changes" we (at least I, but I assume
also KiBi and Paul Wise) mean "what the sysadmin has done by hand
after installing a previous version of the package", not
"what some parts of the package installation have done during
the installation itself".
The dpkg-statoverride --list is meant to ease things in this scenario:
1. The sysadmin installs an older version of the package
1a. Possibly, this older version *during installation* installs
some scripts as owned by userA/groupA
1b. Possbily, this older version *again, during installation, in
a postinst script* fixes those permissions by dpkg-statoverride
to userB/groupB, which is as they usually ought to be, for
99% of the users of this package
2. The sysadmin seems them owned by userB and decides that *for this
particular installation* on her server, the files should instead be
owned either by userC, or, as the case may be, by userA, so
the sysadmin does a dpkg-statoverride to tell the Debian packaging
system that these files really ought to be owned by userC (or userA),
on her machine only.
3. The sysadmin installs a newer version of the package. Since the files
should *normally* be owned by userB, but in this case the sysadmin
has explicitly requested her preference for them to be owned by
userC (or userA), her wishes should not be countermanded without
good reason. Of course, if you, as the maintainer, say that
those files should really, really, REALLY be owned by userB, and
any local changes MUST be countermanded, then, by all means, use
chown - but in that case, it would be better if you did a
"find ... ! ( -user userB -or -group groupB)", and if any files
are found, splash a high priority debconf prompt warning about
them and asking (with default yes) to restore them to userB.
This is what Policy 10.9.1's dpkg-statoverride "list before set"
is meant to do. If your case is the "really, really, REALLY" case
from the last point, then fine, have it your way :) But if it's
just "the maintainer Makefile installs them as userA, but on Debian
systems they ought to be userB *unless the sysadmin decides something
else*", then you should go with dpkg-statoverride.
G'luck,
Peter
--
Peter Pentchev roam@ringlet.net roam@space.bg roam@FreeBSD.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
When you are not looking at it, this sentence is in Spanish.
Attachment:
pgplNEeOGPTcS.pgp
Description: PGP signature