Bugzilla Bug 24178

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 an attachment (id=68944) [details]
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