Gentoo Archives: gentoo-alt

From: "Gregory M. Turner" <gmt@×××××.us>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] eprefixify_patch
Date: Tue, 03 Apr 2012 18:05:49
In Reply to: Re: [gentoo-alt] eprefixify_patch by Fabian Groffen
----- Original Message -----
> On 03-04-2012 08:37:57 -0000, Gregory M. Turner wrote: > > Current prefix SOP is to epatch a bunch of files with > > @GENTOO_PORTAGE_EPREFIX@ and then eprefixify the affected files. > > Although this adds a bit of precision and flexibility, it leads > > to laundry lists in the ebuild, especially if/when we start > > getting more rigorous about prefixification. The attached eclass > > provides eprefixify_patch, which simply prefixifies the patch > > itself before applying. > > Feels dirty too ;)
Admittedly, there is a certain inelegance there. But I can't imagine a real-world scenario which both: would correctly be solved by 'patch + eprefixify'; but would not correctly be solved by eprefixify_patch. It would have to be something like, "well, foo.patch puts '@GENTOO_PORTAGE_EPREFIX@' into 20 different places in '${S}', but only 18 of them are to be eprefixified; the other two are correct patches to the source", which hardly seems like a use-case worth preserving. The idea is to promote clarity and correctness by: o Eliminating redundant information (files in patch vs. files eprefixified in ebuild) o Eliminating potential for error (did we remember to eprefixify all the files that we patched? did we leave behind formerly-eprefixified files in the ebuild?) o Minimizing prefix-specific changes to ebuilds be getting rid of laundry-lists o Encouraging a clear distinction between two types of patches: normal patches, which typically are reverse-able and have legitimate source files as both their input and output, and "eprefixification" patches, which leave the source in an intermediate state, and become pseudo-irreversible once that intermediate state is resolved back to a source-file (plus, this approach makes them reversible again).
> > It also includes some quick & dirty tools to prefixify /bin/{ba,}sh > > shebangs. I'm using both in my overlay. So far, so good. What > > I'm using it /for/ is a more interesting question that I'd like to > > bring up in a separate, presumably more controversial thread. > > Anyhow, for the moment I thought these might come in handy or at > > least precipitate an interesting flamewar :) > > I fail to see how this is necessary. Portage already fixes > those/these shebangs, doesn't it?
Not on my system (which isn't saying much :) )... Where is that supposed to be happening? I have a vague memory of prefix-portage doing this at one time, but the code is not jumping out at me. -gmt