On Thu, Nov 23, 2000 at 01:41:30AM -0800, C.M. Connelly wrote: > > "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.
That is because RPM uses neither root nor a type of fakeroot. This is part of the package program (rpm). The rpm program uses an internal archiver (cpio derivative) that sets the uid/gid itself. IOW, it does everything for you. If you do this for Debian, then I can overcome this problem. Fakeroot cannot be fixed in this case, because of the fact that it is based on preloading a library, which always preloads a libc.so.6 that isn't the one we are using. This library gets preloaded with the new libc.so.6 that we are building. So the problem is unavoidable. > 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. That's because most people do "dpkg-buildpackage -rfakeroot", and it only uses "fakeroot" at this point in the build, not for the entire build. This must be where you are messing up. You need to run "dpkg-buildpackage -rsudo" and not "sudo dpkg-buildpackage". > 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. I only run it on the targets that the package policy defines as needing root. Any other way is wrong (and all packages do this the right way, so don't point fingers at glibc). -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
