Bugzilla Bug 40786

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 an attachment (id=25176) [details]
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 an attachment (id=25449) [details]
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 an attachment (id=25698) [details]
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.