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.
