Bugzilla Bug 96743

Emerging gdbm-1.8.3-r1 fails during the install stage if the "bin" user and
group do not exist.  If they do 
exist, the installation succeeds.

The 1.8.0-r5 version of the ebuild includes a line in src_unpack that
"darwintoolizes" the ebuild 

Emerging gdbm-1.8.3-r1 fails during the install stage if the "bin" user and
group do not exist.  If they do 
exist, the installation succeeds.

The 1.8.0-r5 version of the ebuild includes a line in src_unpack that
"darwintoolizes" the ebuild — this 
seems to generate the appropriate user and group if they don't exist, causing
the ebuild to succeed in 
both cases.  For some reason, this line is missing in the 1.8.3-r1 ebuild. 
Should it still be there?

Reproducible: Sometimes
Steps to Reproduce:
1.  Make sure bin user/group don't exist.
2.  "emerge gdbm"

Actual Results:  
Emerge error during installation phase:

[...snip...]
/usr/bin/install -c -m 644 -o bin -g bin gdbm.h \
        /var/tmp/portage/gdbm-1.8.3-r1/image//usr/include/gdbm.h
install: bin: Invalid argument
make: *** [install] Error 67


Expected Results:  
Successful emerge

Created an attachment (id=61690) [details]
Proposed fix

It turns out that the darwintoolize call is not enough, since it does not
create the bin user/group.  Taking another clue from the 1.8.0-r5 ebuild, you
can create the bin user/group in pkg_setup.  This patch seems to cause the
ebuild to succeed regardless of whether or not bin exists before running
emerge.

thank you douglas!

but be carefull, this patch let emerge use features which need /usr/bin/seq,
this is provided by coreutils-darwin.

Created an attachment (id=68113) [details]
Patch for gdbm-1.8.3-r1.ebuild

get around
"uclibctoolize() is depreciated, please just use libtoolize()!"
and add user/group bin on ppc-macos

We now have a working gdbm again since it was marked stable on 16 Apr 2005.

Fixed in CVS

Why not just install the files as root:root instead of polluting OS X with
users/groups it doesn't need?  There's no reason that gdbm's files need to be
owned by bin:bin, and good security practice says that you don't install files
that aren't owned by root in system directories.  See bug #24178 for a two-line
fix that installs gdbm's files as root:root.

yeah, this fix is wrong

*** This bug has been marked as a duplicate of 24178 ***

If the bin user/group is dropped, then multiple ebuilds seem to be affected to
me, as I decided to solve it this way since other ebuilds do the same already at
the moment.

comment #5 does make sense to me, and I'd prefer not to use user/group bin on OSX.