1 |
On Friday 17 June 2005 04:32, Aron Griffis wrote: |
2 |
> Before working on a solution to the problem, could we get a more |
3 |
> complete list of the tools in question? This has come up before but |
4 |
> the list seems to always end with "etc etc" ;-) |
5 |
Because I don't really know how many applications are available in different |
6 |
flavours.. so that's why we can use eselect so that it can be adapted "on the |
7 |
fly". |
8 |
|
9 |
> Unless I misunderstand you, I don't like this at all. It means that |
10 |
> when an ebuild calls "grep" it doesn't have any idea what the |
11 |
> supported flags are. |
12 |
Well about grep we have no misunderstanding... grep is GNU grep also on the |
13 |
BSD. And actually it has no idea currently about that on G/FBSD or G/OSX.. we |
14 |
condition this using aliases, but the long-term goal is to avoid this. |
15 |
|
16 |
> So far we've been free to exploit GNU extensions (aka |
17 |
> reasonable functionality) in ebuilds. I'd hate to see that go away. |
18 |
Never said it must go away, actually there's no way that it can go away |
19 |
completely but.. .we can ask *explicitely* for GNU tools in those cases |
20 |
(using gsed instead of sed just as an example, or gfind instead of find). |
21 |
|
22 |
> What scripts are you thinking of in this statement? Sometimes |
23 |
> ./configure checks, not always, and AFAIK most other scripts don't |
24 |
> check. |
25 |
Most of them checks for GNU tools when they need them, for example there are a |
26 |
few ./configure which, knowing they need GNU make, in a system where make is |
27 |
BSD and gmake is GNU, launching "make" then exec gmake to do the actual work. |
28 |
|
29 |
> See, it's this "sed stuff is as compatible as possible" thing I don't |
30 |
> like. You're talking about writing to a standard instead of an |
31 |
> implementation. That works for a couple of well-defined compiled |
32 |
> languages, but I don't think it's going to work for shell scripting |
33 |
> (ebuilds), especially when the reality is that we'd be writing to half |
34 |
> a dozen different implementations instead of a standard at all... |
35 |
See above: when we need GNU sed, we can use gsed. |
36 |
|
37 |
|
38 |
> I don't think that switching to g-prefixed commands for GNU utilities |
39 |
> is a good answer. We aren't going to be able to push that upstream, |
40 |
> which means maintaining a lot of patches ourselves. |
41 |
Upstream usually already have this fixed for BSD system for example. I haven't |
42 |
had too much trouble with that before on G/FBSD, for example the only |
43 |
autotool-created makefile which failed on BSD make was gawk, and that just |
44 |
because it used $(RM) var directly; most ./configure scripts checks for rm |
45 |
and creates $(RM) var themselves when make != gmake. |
46 |
|
47 |
> What you're suggesting would cause a lot of pain for the majority of |
48 |
> Gentoo develpers, i.e. the ones running GNU/Linux. |
49 |
As we are now, on G/FBSD we have anyway quite all the GNU utilities (but for |
50 |
example we don't need tar and about find we can use the BSD's one with |
51 |
ebuilds. |
52 |
|
53 |
Anyway, as I already had done, I'm here to fix in case something is using the |
54 |
wrong way... after a couple of examples this can be quite simple as for the |
55 |
old gnu-find dependent ebuilds which are now fixed. |
56 |
|
57 |
-- |
58 |
Diego "Flameeyes" Pettenò |
59 |
Gentoo Developer - http://dev.gentoo.org/~flameeyes/ |
60 |
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) |