| 1 |
On 02-10-2007 09:48:06 +0100, Roy Marples wrote: |
| 2 |
> > What is your rationale to say that "pure sh" is a "bonus"? Especially |
| 3 |
> > given the environment this is used in as ferdy already pointed out? |
| 4 |
> |
| 5 |
> The bonus is that it works on shells other than bash. |
| 6 |
|
| 7 |
I give you a big chance Solaris' or AIX' /bin/sh won't grok this stuff. |
| 8 |
|
| 9 |
> > I personally like consistency. So if we use bash in ebuilds, then I'd |
| 10 |
> > like to use bash in eclasses too. I'm interested in your motivation to |
| 11 |
> > make this eclass "pure sh", whatever that may mean. |
| 12 |
> |
| 13 |
> I like consistency too, and I'll be pushing for using sh instead of |
| 14 |
> forcing bash. |
| 15 |
|
| 16 |
I admire your courage. |
| 17 |
|
| 18 |
> My motivation? Simple. I don't believe that the portage tree should be |
| 19 |
> locked into using one shell. I believe that vendor lock-in should happen |
| 20 |
|
| 21 |
"vendor lock-in" is an interesting term to mention here, as bash is open |
| 22 |
source, and I think (I'm not a lawyer) free to use as long as you want, |
| 23 |
and modifyable if you like. |
| 24 |
|
| 25 |
> at the social level, not the technical one. portage itself was a lock-in |
| 26 |
> until until PMS came about, now I'd like to remove the lock-in from the |
| 27 |
> tree itself. This in itself is a good thing as we can pick and choose |
| 28 |
> the tools we want to use as they're all playing on the same field. |
| 29 |
> |
| 30 |
> This same rationale applies to scriptlets outside portage tree use, such |
| 31 |
> as revdep-rebuild [1]. It's more of a bashlet, but I've also |
| 32 |
> demonstrated that there was no reason to force bash there. |
| 33 |
> |
| 34 |
> Obviously there are more lock-ins than just the shell, but it's a good |
| 35 |
> start. |
| 36 |
|
| 37 |
Given my own "history" I have a hard time to believe you are persuing |
| 38 |
the right track here. It may or may not be a secret that I currently do |
| 39 |
the complete opposite of what you're trying to do -- so far with a good |
| 40 |
lot of success, especially given the number of completely different |
| 41 |
platforms. |
| 42 |
|
| 43 |
Question from me to you is, whether your vision is just to get (Free)BSD |
| 44 |
working seamlessly with Gentoo, or whether you also look beyond your |
| 45 |
current scope to the "Meta Distribution". This includes the benefit of |
| 46 |
moving from bash to POSIX(?) sh as standard kit to interpret the meta |
| 47 |
information. Changing init.d scripts is one thing, changing the |
| 48 |
definition of how the meta information should be read is another thing. |
| 49 |
|
| 50 |
|
| 51 |
-- |
| 52 |
Fabian Groffen |
| 53 |
Gentoo on a different level |
| 54 |
-- |
| 55 |
gentoo-dev@g.o mailing list |
Archives