Fabian Groffen wrote:
> On 17-09-2008 10:21:17 +0200, Santiago M. Mola wrote:
>> >> Why not simply alias patch=gpatch in profile.bashrc?
>> >> See the FreeBSD profile for an example.
>> >>
>> >
>> > I'd like to package portage for OpenSolaris and have it just drop-in
>> > work so modifications like what you suggest wouldn't be required.
>>
>> You'd still need to create an OpenSolaris profile. While you're at it,
>> you can create a profile.bashrc with the required modifications.
>>
>> I don't see any reason to not do the gpatch change, but it looks like
>> unecessary to me because you already have simpler ways to solve the
>> problem. So, requiring others to do a significant useless amount of
>> work when you can solve it with just a line is not fair.
>
> From some experience, I can tell that an alias is not sufficient to
> cover all cases, and will result in random failures because you only
> notice too late patch is used and not gpatch.
>
alias only works for stuff that bash parses as a command on tokenisation. So
it won't work for anything called via a variable, or find -exec/xargs.
(Note also the standard way to get round an alias: \foo or `command foo'.)
> By the way, I'm against this stuff. I rather see a PATH solution
> involved. Portage already has a DEFAULT_PATH, and if someone refuses to
> install patch, one could always use a special directory with symlinks to
> the g-versions, e.g. patch -> /usr/sfw/bin/gpatch such that
> Portage/eclass/ebuilds don't have to bother about this at all.
>
I agree. PATH+=':/blah/bar', or PATH="/blah/bar:$PATH" if you want it
considered first.
The alternative would be a variable for every utility that could conceivably
be called, and then every ebuild would need to use those, which is a
maintenance nightmare imo. I guess you could ban use of -exec/xargs but I
don't think that's likely ever to happen.
