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 attachment 61690 [details, diff] 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 attachment 68113 [details, diff] 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.
