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.
