Bug 60721 – etc-update doesn't work on Mac OS X

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Mamoru KOMACHI (RETIRED) 2004-08-17 17:31:43 UTC]

etc-update utility doesn't work properly on Mac OS X. This is because /etc on Mac OS X is a symbolic link to /private/etc and find doesn't follow it (other CONFIG_PROTECTed directories are fine). I will attach a patch to fix the problem. (Simply add / to CONFIG_PROTECTed directories for find to follow symbolic links and remove the / afterwards.)

[Comment 1 Mamoru KOMACHI (RETIRED) 2004-08-17 17:32:25 UTC]

Created attachment 37634 [details, diff]
etc-update-macos.diff

[Comment 2 Brian Harring (RETIRED) 2004-08-26 19:07:42 UTC]

Thanks Mamoru; it'll pop up in the next release after .51_pre20

[Comment 3 Mamoru KOMACHI (RETIRED) 2004-09-11 08:50:48 UTC]

portage-2.0.51_pre23 seems to include the patch, but it needs another patch to include
(etc-update in _pre23 depends on GNU sed, so I added a function to wrap sed to use gsed).

[Comment 4 Mamoru KOMACHI (RETIRED) 2004-09-11 08:51:55 UTC]

Created attachment 39400 [details, diff]
a simple diff to use GNU sed if USERLAND is BSD

alias didn't work

[Comment 5 dario 2004-09-11 08:52:56 UTC]

I don't know if there are other changes from _pre20, but in _pre23 etc-update is still having trouble.
The bug is in get_config(), I didn't understand what exactly do the regexp, but this patch for me works(probably it's a dirty fix):

--- etc-update.orig     Sat Sep 11 17:38:49 2004
+++ etc-update  Sat Sep 11 17:47:25 2004
@@ -19,7 +19,7 @@
        # item. If there's more than one of the same configuration item,
        # then allow the last setting to take precedence.
        cut -d'#' -f1-1 /etc/etc-update.conf | \
-               sed -ne "s/^ *$item *= *\([\"']\{0,1\}\)\(.*\)\1/\2/p" |sed -e '$p;d'
+               sed -ne "s/^ *$item *= *\([\"']\{0,1\}\)\(.*\)\1/\2/p" |sed -e '$p;d'|sed -e "s/[\"\']$//"
 }
 
 function scan() {

[Comment 6 dario 2004-09-11 08:55:44 UTC]

too late, sorry ;)

[Comment 7 Pieter Van den Abeele (RETIRED) 2004-09-24 19:08:50 UTC]

What's the current status on this bug?

[Comment 8 Jason Stubbs (RETIRED) 2004-09-24 19:28:14 UTC]

Is/will *BSD be using the same method for handling sed/gsed et al?

[Comment 9 Otavio Piske (RETIRED) 2004-09-27 09:08:07 UTC]

Jason, yes. We'll use the same thing to handle sed/gsed. I tested the second patch (to test if the userland is BSD) and it worked without any problems in my Gentoo/FBSD system. 

[Comment 10 Mamoru KOMACHI (RETIRED) 2004-10-01 02:07:18 UTC]

Thanks, it's fixed in _rc7. However, stacked profile (default-macos/ppc/10.3/make.defaults)
set USERLAND="macos", and my make.conf set it to BSD (this comes from Gentoo for Mac OS X
installer). Which is correct? (pvdabeel sent a mail to macos@g.o that we use USERLAND="macos",
which would break this patch in the future)

[Comment 11 Hasan Khalil (RETIRED) 2004-10-01 08:03:46 UTC]

USERLAND is set to BSD, as is hardcoded in portage, no matter what you set it to in make.conf. Do a grep on USERLAND and BSD on the portage code, or just throw an echo in an ebuild. This is definately a problem if it's supposed to be 'macos' as pvdabeel said. I opened a bug about it but it was closed (and misunderstood?) - bug 64510.

[Comment 12 Jason Stubbs (RETIRED) 2004-10-01 17:20:12 UTC]

USERLAND is an internal portage variable. Profile's shouldn't be defining it and ebuilds should not need to ever make use of it. GLEP22 does not require it to be set at all.

[Comment 13 Grant Goodyear (RETIRED) 2004-10-01 20:44:20 UTC]

Um, I believe that drobbins added the USERLAND variable long ago for macos, and I
co-opted it for *BSD.  That said, I agree that nobody should be using it.
Ideally, we should be abstracting those calls that have different semantics
between platforms so that ebuild authors can ignore the details as much as
possible.  

[Comment 14 Mamoru KOMACHI (RETIRED) 2004-10-05 04:02:11 UTC]

Removed USERLAND="macos" from stacked profiles. 
All fixed in CVS. Thanks!