Y'all might shoot me for this one, but sys-apps/sed's configure script is dependant on sed to work. Surprisingly, it's not a CANTFIX. The normal sed installation can actually run a make install to install a working sed installation, without using configure. So... I'll be posting a patch to the ebuild to enable this behaviour. It's useful for cases where a user either accidentally hoses sed, or intentionally does (as I did).
Created attachment 25176 [details, diff] sed-4.0.7.ebuild patch, to enable detection of a missing sed, and bootstrap a temporary working bin. It may not be a bad idea to have this ebuild always bootstrap a working copy, depending on how well it behaves across arches. The reason I wonder about this, is mainly since it tests if sed exists, if it does, but say is corrupted, it would still try to use the corrupted version.
ebuild.sh's unpack function uses sed; I've added 40819 (a patch to remove ebuild.sh's reliance on sed) as a blocker for this bug, since w/out those modifications, this patch is worthless- it wouldn't matter if the ebuild knows how to build a temporary sed, ebuild.sh would fail to even unpack the src.
I do not know if you had a bad sed experience or such, but I do not see the need for this fluff. There are much worse cases that I can think of where some base tool have been unmerged (I do not see how you will do anything if you unmerge gcc/binutils/glibc without an binary package, even more of a pain is if you unmerge tar). Sed is easy - you can create a perl script and cp it to /usr/bin/sed to get you mostly going. Seemant, as sed is your baby ... ?
I'm not opposed to this idea of bootstrapping a sed in order to build a sed, so long as we can do it elegantly.
ok, here's my feeling -- I'd rather that the bootstrapped bin is installed into WORKDIR so that the real sed can still be built. I don't like the idea of having to emerge sed twice.
when i have to mess with stuff in PATH i just put the temp script in $T and then just PATH="${T}:${PATH}" ... in this case i think adding a small detection algorithm isnt a bad idea (if `which sed` returns false then bootstrap)
Created attachment 25449 [details, diff] sed-4.0.7.ebuild.patch v2 Switched over to using which sed instead, removed the 'echo "install *temporary* sed"' since it was inaccurate. If ${T} is a preferred location, I can modify the patch to transfer the bin there, and set the PATH="${T}:${PATH}" rather then using the binary directly out of it's src dir (PATH="${S}/sed:${PATH}").
I still do not see the need, but Ok. What really bothers me about things such as this, is it creates a president (but you did it for package foo ...). I would rather us stick to "if you screwed up package foo/bar-x.y.z, then get the binary package. This might also be a good time to consider also having broken-out .tbz2's for each release ... ?
Created attachment 25698 [details, diff] sed-4.0.7.ebuild patch v3 Updated it, I now know what seemant was talking about with needing to re-emerge it twice. Basically, now it bootstraps a quick sed, transfers it to ${T} (ala SpanKY), wipes clean all intermediate objects (if you don't do this, you'll end up needing to re-emerge sed due to the temp sed being used).
fixed in 4.0.9 and 4.1.2
Spanky you rock.
