Re: [gentoo-portage-dev] [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races

[Greg Turner]

On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
 +   sed -i \
 +   -e 
 1s:^#![[:space:]]*/bin/sh:#!$CONFIG_SHELL: \
 +   ${ECONF_SOURCE}/configure \
 +   || die Substition of shebang in 
 '${ECONF_SOURCE}/configure' failed

Shouldn't we take the same copy, ${pid}-suffix, move approach, here
that we've done with config.{sub,guess}?  Otherwise, what's to stop
these sed's from trampling each other's work-in-progress (the fact
that ebuilds don't crash left and right does suggest that some
mechanism actually does prevent this, already -- but it's a mystery to
me, and I worry it could be some kind of linux-specific filesystem
quirk).

-gmt

[gentoo-portage-dev] musings on config.{sub,guess} replacement living in econf (was: [PATCH] econf: update configure/config.{sub,guess} atomically to avoid races)

[Greg Turner]

On Tue, Dec 17, 2013 at 3:28 PM, Mike Frysinger vap...@gentoo.org wrote:
 URL: https://bugs.gentoo.org/487478

Perhaps, with this bug resolved, this matter falls under the more
trouble than its worth to fix category -- but...

My hunch is that the decision to put the config.{sub,guess}
replacement code in econf was intended as a quick-and-dirty way to
avoid doing the replacements, in cases where no configure script runs
in an ebuild.

Post EAPI-2, the convention that hacking on the sources in ${S}  is
a no-no after src_prepare has clearly crystallized considerably (I'm
guessing the code has EAPI-[01] origins); violating that convention in
econf seems awkward.

Further, the approach has a few other non-fantastic qualities:

o It doesn't run, if, for some reason, the ebuild must invoke
   configure directly rather than use econf

o when econf is invoked repeatedly, it does the same
   O(# of dirs in ${S}) noop over and over

In short... moving the config.{sub,guess} replacement code (but
probably not the shebang patching for reasons of expedience) to some
post-src_prepare place would probably be more elegant and pretty easy
to do.

As for the only replace if we econf issue, I can't imagine that
simply doing the replacement unconditionally would be so bad (perhaps,
with a hard-coded gnuconfig exemption, if that's needed).

Anyhow, it's very much not a big deal.  #487478 (which was entirely
theoretical, to begin with) is fixed, and there are way bigger fish to
fry in Gentoo-land... just thought I'd mention it, though, mostly as
an open note-to-self, I guess.

-gmt