On Tue, Mar 02, 2010 at 12:00:25PM +0100, Dominik George wrote: > > On Tue, 2 Mar 2010 12:37:25 +0200, Peter Pentchev <firstname.lastname@example.org> > wrote: > > On Sat, Feb 27, 2010 at 12:23:25AM +0100, Cyril Brulebois wrote: > >> Dominik George <email@example.com> (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 firstname.lastname@example.org email@example.com 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.
Description: PGP signature