"BC" => Ben Collins <[EMAIL PROTECTED]>
Me> [*] One extremely annoying discovery was that the libc6
Me> packages *must be built as root*. Leaving aside the
Me> question of *why* the packages can't be built with
Me> fakeroot (or as an ordinary user, even) -- the Red Hat
Me> RPMs do not require you to be root -- it would have been
Me> really nice if the package had checked for root *first*,
Me> rather than running for 4.5 hours and only then realizing
Me> it couldn't finish.
BC> Problem is, fakeroot preloads a library to "fake"
BC> things. This is bad when working with building a system
BC> lib such as glibc. It has caused many bugs before, which
BC> is why I explicitly forced the glibc to make sure it was
BC> using real root, and not fakeroot.
If fakeroot causes problems, then perhaps we should either fix it
so that it causes fewer problems, or figure out a way to avoid
using it. Other packaging systems, such as RPM, allow people to
build packages as ordinary users, and that includes glibc -- my
partner has built RPMs of several versions of glibc over the past
few days on a faster machine where root access wasn't an option.
Until dpkg includes that functionality, however, I'll believe you
when you say that fakeroot causes some problems and accept that
the safest workaround is to build the packages as root.
BC> This wont change, and the "4 hours later" problem is a
BC> result of the Debian build process, not something specific
BC> to glibc.
Except that the test comes right at the end and is both defined in
and performed by code in the debian/rules file:
define checkroot
@test root = "`whoami`" || (echo Need root privileges; exit 1)
@test -z "$$FAKEROOTKEY" || (echo Need to compile as root, not
fakeroot; exit 1)
endef
This code is called (as ``$(checkroot)'') at the start of the
``install'' target, which is one of the last targets to run during
the build process. If you can run this test just before building
packages, you can run it earlier in the process -- preferably
right at the very beginning (in the ``configure'' target), before
the builder has walked away, expecting to come back to a set of
freshly built glibc packages.
You could even perform the test for *each* target, which would
help if someone was running an intermediate target rather than
starting the build process from scratch.
Even better -- you could perform the test at the start of the
build, and if the user wasn't root, you could print a message to
the effect that the libraries could be built as an ordinary user,
but that the user would need root privileges to build the
packages. The test at the ``install'' target could then print
some useful information about resuming the build, if that's
possible. I opted to start over because I wasn't sure whether the
problem was related to building the packages or building the
libraries (and I wasn't planning to use my machine for anything
else), but if I had known that it was safe to just su to root and
type ``debian/rules binary'' (or whatever), I would have done so.
At the very least, you could have the build script print an
obnoxious message on the terminal that warns the user that they
need to be root. Maybe something like
**********************************************************
WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
**********************************************************
**** ****
**** This package cannot be built with fakeroot! ****
**** ****
**** Please do at least one of the following: ****
**** * Build as root ****
**** * Devise workarounds for fakeroot's ****
**** deficiencies ****
**** * Rewrite fakeroot so it works ****
**** * Rewrite dpkg so you don't need to be ****
**** or pretend to be root ****
**** ****
**** ('su'ing is the easiest one, I think.) ****
**** ****
**********************************************************
WARNING! WARNING! WARNING! WARNING! WARNING! WARNING!
**********************************************************
would do the trick....
Thanks,
CMC
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Behind the counter a boy with a shaven head stared vacantly into space,
a dozen spikes of microsoft protruding from the socket behind his ear.
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
C.M. Connelly [EMAIL PROTECTED] SHC, DS
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
