Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 58087 - Ebuilds using "sed -i" fail on OS X
Summary: Ebuilds using "sed -i" fail on OS X
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: PPC Linux
: Normal minor (vote)
Assignee: osx porters
Depends on: 58415
  Show dependency tree
Reported: 2004-07-23 10:02 UTC by Andreas Schwarz
Modified: 2005-02-06 13:33 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Schwarz 2004-07-23 10:02:43 UTC
The -i option for sed doesn't work with sed on OS X. Because sed is injected as 4.0.2 on bootstrap even ebuilds depending on sed >= 4 break.

Reproducible: Always
Steps to Reproduce:
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2004-07-23 12:16:25 UTC
does supersed work?
Comment 2 SpanKY gentoo-dev 2004-07-23 13:24:25 UTC
this is a problem for the OS X people to figure out ... i can tell you right now that changing ebuilds to not use -i is the wrong way to go

you have two choices the way i see it ...
(1) utilize supersed and trick the portage env to execute that (but iirc, supersed itself has problems that broke packages in the past)
(2) replace the bsd sed with the GNU-4.x version in the system
Comment 3 Nick Dimiduk (RETIRED) gentoo-dev 2004-07-23 13:29:47 UTC
Rather than replace, could we install gnu sed (and other gnu utilities for that matter) to some other dir and set the portage environment $PATH such that it references the gnu utilities rather than the BSD defaults?
Comment 4 SpanKY gentoo-dev 2004-07-23 14:49:31 UTC
ah, that's even a more intelligent option than what i suggested :)
Comment 5 Andreas Schwarz 2004-07-23 15:02:27 UTC
I replaced BSD make, but I don't think it's a very good solution. Maybe the whole gentoo stuff should be installed in a special directory (like fink)?
Comment 6 Nick Dimiduk (RETIRED) gentoo-dev 2004-07-23 17:08:50 UTC
My problem with using a seperate directory like fink is two-fold.

1.  It strays from the unix file system standards

2.  We don't get the default benefits of using existing software/libraries already installed without modification.

Using our own seperate directory structure results in a completly seperate installation structure, nearly a chroot environment.  There will be a lot of duplication if we do this.  I don't see why we can't work some $PATH magic and and work this out.  We simply need to be aware of what already exists in the core system and use it, not replace it unless we have to.  If we can do this, Gentoo/BSD and Gentoo/Darwin will be easier.
Comment 7 Grant Goodyear (RETIRED) gentoo-dev 2004-07-23 19:45:20 UTC
For Gentoo/*BSD we install GNU sed, patch, and make (I might be missing something) using a "g" prefix (creating gsed, gpatch, and gmake), and has "alias sed=gsed; alias patch=gpatch; alias make=gmake" if USERLAND=BSD.  (Oh, add tar/gtar to that list.)
Comment 8 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-07-23 22:11:31 UTC
Forcing replacement of BSD sed is not an option (not a few
people want to overwrite their Mac OS X default distribution).
Rather we choose either

a) install GNU sed in different location other than /usr/bin (Comment
#3, #5 and #6)
b-1) install GNU sed with different name and wrap it with portage
(Comment #7)
b-2) use different sed (supersed? I think sed_inplace from FreeBSD also
works) and wrap it with portage (Comment #2 and #7)

In my opinion, option a) is the ultimate goal as we are moving toward
prefixed install. However, I'm against that we make special directory
for _GNU_ utilities and tweak PATH to execute them. It is because the
same thing applies to emacs, perl, ruby, python and whatever you
already have in Mac OS X distribution.

Option b) seems more or less good for temporal solution. It will work
if we are to inject sys-darwin/sed-4 instead of sys-apps/sed-4 (if we
inject sys-apps/sed-4 we cannot tell portage to pull in GNU sed or

Given that we take option b), I think of two implementations of
wrapping sed. On the one hand we can wrap sed in as vapier
and g2boojum suggested, and then add whatever sed we choose to
default macos system profile (otherwise all the ebuilds depending
on sed implicitly will break). On the other hand, we would make
sed eclass and export sed function. This eclass will insert
necessary sed to DEPEND and wrap it for macos. Also, it will instert
>=sys-apps/sed-4 to DEPEND if arch is not macos. I think the latter
is better because you can remove >=sys-apps/sed-4 deps from your
ebuild and you can change sed dependency if it turns out to cause
Comment 9 SpanKY gentoo-dev 2004-07-23 22:16:16 UTC
just so we're clear ... adding hacks to ebuilds / eclasses is not an option ...

as grant showed, it can easily be handled in portage
Comment 10 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-07-23 22:50:04 UTC
ok, so what we are going to do is - 

1) remove sys-apps/sed-4.0.2 from profiles/default-macos-10.*/
  (sed is provided by sys-darwin/text_cmds)
2) modify sys-apps/sed-4 to rename sed to gsed when ${USERLAND} is BSD
3) add *>=sys-apps/sed-4 to profiles/default-macos-10.*/packages
4) modify to use gsed when ${USERLAND} is BSD

Everyone happy with this? (I'm not saying anything about gtar, gpatch
and gmake this time, since I haven't met any ebuilds broken with BSD
tar, patch and make at this point)
Comment 11 Erik Swanson (RETIRED) gentoo-dev 2004-07-23 23:05:20 UTC
Instead of installing another sed, couldn't we create a wrapper (used via path magic) that fakes -i inline support?
Comment 12 Pieter Van den Abeele (RETIRED) gentoo-dev 2004-07-24 04:10:22 UTC
Comment 10, number 4: This is the default in portage, I had uncommented it to make it work out of the box. We should probably also add gsed to the default profile. (thinking of adding dev-python/readline for repoman too) 
Comment 13 Lina Pezzella (RETIRED) gentoo-dev 2004-08-05 11:45:42 UTC
Once support for exploding keywords is in the stable version of portage, all references to 'use macos' should be changed to look for a BSD userland instead (so that the BSD guys can mooch off our work  :)  Comment #10 point #4 will be deprecated as soon as pre17 makes stable portage.  Please add alias sed=gsed to the appropriate per profile bashrc's.

sed-4.0.9.ebuild changes committed to cvs.  You may now install gsed. ;-)
Comment 14 Lina Pezzella (RETIRED) gentoo-dev 2004-08-09 07:42:10 UTC
Added to emerge system and aliased in profile.bashrc.
Comment 15 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-10-23 23:48:29 UTC
I reinstalled Gentoo for Mac OS X several days ago, 
and noticed the following issue:

1) emerge system tries to install sys-apps/sed
2) sys-apps/sed depends on gnuconfig
    (sed runs gnuconfig_update inside the ebuild)
3) gnuconfig calls sed from gnuconfig.eclass, 
and sed is aliased to gsed by profile.bashrc
    (and fails to execute)

It is not harmful to leave it as it is because 
sys-apps/sed installs correctly without running 
gnuconfig_update, but I think it is better to
fix it. I suggest changing 

alias sed=gsed


[ -x /usr/bin/gsed ] && alias sed=gsed

as gnuconfig_update is not using "sed -i".

Any other ideas?
Comment 16 Kito (RETIRED) gentoo-dev 2004-11-14 17:50:14 UTC
thats sounds fine to me. You want to add it and re-close this?
Comment 17 Lina Pezzella (RETIRED) gentoo-dev 2004-11-15 09:47:35 UTC
You have my vote.
Comment 18 Nick Dimiduk (RETIRED) gentoo-dev 2004-11-15 11:09:43 UTC
Looks like the best solution to me.
Comment 19 Mamoru KOMACHI (RETIRED) gentoo-dev 2004-11-16 08:10:07 UTC
Fixed in CVS :)
Comment 20 Hasan Khalil (RETIRED) gentoo-dev 2005-02-06 13:33:25 UTC
Closing out bugs that've been resolved for a while now...