gdbm installs its files with bin:bin ownership instead of root:root. Here's an ebuild patch: diff -u gdbm-1.8.0-r5.ebuild.orig gdbm-1.8.0-r5.ebuild --- gdbm-1.8.0-r5.ebuild.orig 2003-06-22 01:21:43.000000000 -0500 +++ gdbm-1.8.0-r5.ebuild 2003-07-09 09:49:27.000000000 -0500 @@ -41,12 +41,12 @@ } src_install() { - make prefix=${D}/usr \ + make BINOWN=root BINGRP=root prefix=${D}/usr \ man3dir=${D}/usr/share/man/man3 \ infodir=${D}/usr/share/info \ install || die - make includedir=${D}/usr/include/gdbm \ + make BINOWN=root BINGRP=root includedir=${D}/usr/include/gdbm \ install-compat || die dosed "s:/usr/local/lib':/usr/lib':g" /usr/lib/libgdbm.la Reproducible: Always Steps to Reproduce: 1. 2. 3.
Wonder why this was assigned to me.
what's the problem when ownership is wrong ?
finally fixed, since econf and emake are used now
The problem when the ownership is wrong is that it's bad form to install files that aren't owned by root in system directories. There's no reason gdbm's files need to be owned by bin:bin. In fact, this later caused bug #96743 because Mac OS X doesn't have user/group bin. And no, using econf and emake doesn't fix the problem. BINOWN and BINGRP are hardcoded to "bin" in Makefile.in and aren't affected by configure.
*** Bug 96743 has been marked as a duplicate of this bug. ***
Created attachment 68944 [details, diff] gdbm-1.8.3-r1.ebuild patch which uses suggested fix on OSX the group of root is wheel, so we cannot hardcode root:root here. I attached a patch where I revert the OSX specific bin user/group creation and use the suggested BINOWN and BINGRP variables to set the root user and it's primary group via a call to `id -gn root`. I'm not sure on whether this is the right way to do it, but it appears to work on OSX and linux.
thinking this over, we could just use uid=0 and gid=0 instead of trying with names and avoid the `id -gn root` call. However, if portage ever will allow non-root installs, then it would require here to use `id -u` and `id -g` for user and group respectively.
Hoist on my own petard. :) Should have used 0 instead of root, sorry about that. (In my defense, it _is_ an old patch and predates the "which group is gid 0?" saga.) As for non-root installs, I'd be tempted to just rip out the Makefile bits that set the ownership and send the patch upstream. There's just no need for gdbm to set the file ownership at all, IMO.
fixed in cvs
