Bug#203650: Poor recommendation in dpkg-statoverride section

[Carl Witty <cwitty@newtonlabs.com>]

On Thu, 2003-07-31 at 10:39, Colin Watson wrote:
> On Thu, Jul 31, 2003 at 06:24:18PM +0100, Andrew Suffield wrote:
> > So, let's break down what happens a bit:
> > 
> >  - dpkg unpacks the files, with their original permissions
> >  - postinst creates a user
> >  - postinst adds a statoverride to change the permissions
> > 
> > The "problem" is that the user doesn't exist until after you unpack
> > the files. Adding a statoverride here is a somewhat strange approach
> > in its own right, ignoring such matters as the period between unpack
> > and configure when permissions/owners are wrong.
> > 
> > I suggest that this sequence would make more sense:
> > 
> >  - preinst creates a user
> >  - dpkg unpacks the files
> > 
> > It's easier to understand and doesn't tread on the admin's toes as
> > much. Note that dpkg stores users by name, not by uid.
> 
> How should you ensure that the user in question exists on the system
> building the package?

If somebody were willing to put a fair bit of effort into this, I think
the following would work:

If a package should contain files owned by the user "grinch", then
debian/rules must execute the command
	fakeroot-createuser grinch
This command first checks whether a user "grinch" already exists; if so,
it does nothing.  If not, it uses some private communication channel to
tell fakeroot to pretend this user exists.  If this fails, then it is
not running under fakeroot; it prints a message something like the
following:
	To build this package, you must either create a user "grinch"
	or do the build under fakeroot.

As the error message indicates, this should allow the package to be
built either by creating the user and building the package as root, or
by building the package using fakeroot.

Of course, this is a lot of effort to avoid temporarily having files
with the wrong owner/permissions during installation.

Carl Witty