Re: [gentoo-dev] RFC: sh versionator.eclass
On 07-10-2007 16:37:21 -0600, Joe Peterson wrote:
1) Limit tool options to those that are common to all tool variants
2) Port a standard (i.e. GNU) set of tools to all platforms
3) Force all gentoo ports to use GNU userland
...
No, it is not. The problem IMHO is in the user userland and the
portage userland are being seen as one. I think it would be very easy
to install all GNU equivalents of tools on BSD in some separate dir, put
it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work
perfectly well from the ebuild/eclass perspective.
Yep, that's option #2, and I think that could work - a subset of
commands in their GNU variants used by portage. It means formalizing
the official set of tools allowed for use in ebuilds (I'm not sure if
the dev guide really codifies this or not, even though it gives a list
of such tools).
Ok, then I misunderstood. Most important thing is that we agree that
this looks like it /is/ the way to go.
What I meant above is that #3, which would be changing all of userland
itself to GNU, would be major and undesirable. Having the option of a
complete GNU userland would be an interesting option/project, but it's a
good thing to have the flexibility to have any userland desired, as long
as portage has a way of being consistent (i.e. via something like #2).
If you want a GNU userland on FreeBSD, Solaris, Darwin, etc. I think you
should look at Prefix where [[ ${USERLAND} == GNU ]] always holds. ;)
--
Fabian Groffen
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
Mike Frysinger wrote: as mentioned, GNU is the main bread and butter of Gentoo. forcing the majority of people to go pure POSIX in the face of GNU extensions that make life easier is wrong. so the minority gets screwed, that's life. especially considering it's trivial for the minority to conform. -mike Hi Mike, I totally agree that we should be careful about trying to force pure POSIX on ebuild writers, and you are right that GNU is the majority. I do see an issue here, though, and I am not sure what the best solution is. Ebuilds have to work across various platforms, including the Gentoo/Alt ones, and it is common practice to use external tools (like find, etc.), and unlike eclasses, they can behave differently on different platforms (at least the way things are set up now). Ebuilds already have to limit themselves to using tools from a core set that exist on all systems, of course, but if options to these tools are used that do not exist on all platforms, the ebuild is not portable, and that's the crux of the issue. So there are a couple of options, as I see it: 1) Limit tool options to those that are common to all tool variants 2) Port a standard (i.e. GNU) set of tools to all platforms 3) Force all gentoo ports to use GNU userland I think we'd all agree that #3 is too restrictive. For example, g/fbsd uses BSD's userland (like vanilla FreeBSD does), and making it GNU would be a pretty major change. #2 is would be feasible, but namespace collisions would result unless we did something like prepend g to the tools and perhaps place them in a standard dir where ebuilds will look for them first. This would even more formally define the core set of tools allowed, and I'm not sure if this is a good or bad thing. #1 is the one you object to, and I am torn on this one. I agree with you that we don't necessarily want to deny ebuilds nice features included in only the GNU variants, but then again, the Gentoo Development Guide does recommend avoiding GNU-specific options for, I assume, this reason: http://devmanual.gentoo.org/tools-reference/find/index.html So, comments? -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Sun, 2007-10-07 at 01:06 -0400, Mike Frysinger wrote:
You can also do some pattern matching like so
foo=foo foobar
[ ${foo%foobar} = ${foo} ] || echo ends with foobar
[ ${foo#foobar} = ${foo} ] || echo starts with foo
[ ${foo#* } = ${foo} ] || echo has a space
So there's no need for convoluted nested case statements.
no need implies that everything can be done, but you started off
with some ...
Yes, the some being =~, which is the only operator I know of that cannot
be done with posix sh
you're still going from one clean logic statement to multiple
ones where the nested logic gets to be a pita to track. again, this
is a sad/unacceptable solution.
OK, it's time to pony up - show me a code snippet which you think a
nested code snipet which you think is unworkable in posix sh when
transitioning from [[ ]] to [ ].
=~ isn't allowed as that's a strict bashism.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On 07-10-2007 10:19:43 -0600, Joe Peterson wrote: So there are a couple of options, as I see it: 1) Limit tool options to those that are common to all tool variants 2) Port a standard (i.e. GNU) set of tools to all platforms 3) Force all gentoo ports to use GNU userland I think we'd all agree that #3 is too restrictive. For example, g/fbsd uses BSD's userland (like vanilla FreeBSD does), and making it GNU would be a pretty major change. No, it is not. The problem IMHO is in the user userland and the portage userland are being seen as one. I think it would be very easy to install all GNU equivalents of tools on BSD in some separate dir, put it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work perfectly well from the ebuild/eclass perspective. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
Fabian Groffen wrote: On 07-10-2007 10:19:43 -0600, Joe Peterson wrote: So there are a couple of options, as I see it: 1) Limit tool options to those that are common to all tool variants 2) Port a standard (i.e. GNU) set of tools to all platforms 3) Force all gentoo ports to use GNU userland I think we'd all agree that #3 is too restrictive. For example, g/fbsd uses BSD's userland (like vanilla FreeBSD does), and making it GNU would be a pretty major change. No, it is not. The problem IMHO is in the user userland and the portage userland are being seen as one. I think it would be very easy to install all GNU equivalents of tools on BSD in some separate dir, put it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work perfectly well from the ebuild/eclass perspective. Yep, that's option #2, and I think that could work - a subset of commands in their GNU variants used by portage. It means formalizing the official set of tools allowed for use in ebuilds (I'm not sure if the dev guide really codifies this or not, even though it gives a list of such tools). What I meant above is that #3, which would be changing all of userland itself to GNU, would be major and undesirable. Having the option of a complete GNU userland would be an interesting option/project, but it's a good thing to have the flexibility to have any userland desired, as long as portage has a way of being consistent (i.e. via something like #2). -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Sunday 07 October 2007, Roy Marples wrote:
On Sun, 2007-10-07 at 01:06 -0400, Mike Frysinger wrote:
You can also do some pattern matching like so
foo=foo foobar
[ ${foo%foobar} = ${foo} ] || echo ends with foobar
[ ${foo#foobar} = ${foo} ] || echo starts with foo
[ ${foo#* } = ${foo} ] || echo has a space
So there's no need for convoluted nested case statements.
no need implies that everything can be done, but you started off
with some ...
Yes, the some being =~, which is the only operator I know of that cannot
be done with posix sh
you're still going from one clean logic statement to multiple
ones where the nested logic gets to be a pita to track. again, this
is a sad/unacceptable solution.
OK, it's time to pony up - show me a code snippet which you think a
nested code snipet which you think is unworkable in posix sh when
transitioning from [[ ]] to [ ].
i never mentioned =~. i already gave perfectly acceptable examples of using
== with pattern matching and your unacceptable workaround was to use
[possibly nested] case statements.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Sunday 07 October 2007, Fabian Groffen wrote: On 07-10-2007 10:19:43 -0600, Joe Peterson wrote: So there are a couple of options, as I see it: 1) Limit tool options to those that are common to all tool variants 2) Port a standard (i.e. GNU) set of tools to all platforms 3) Force all gentoo ports to use GNU userland I think we'd all agree that #3 is too restrictive. For example, g/fbsd uses BSD's userland (like vanilla FreeBSD does), and making it GNU would be a pretty major change. No, it is not. The problem IMHO is in the user userland and the portage userland are being seen as one. I think it would be very easy to install all GNU equivalents of tools on BSD in some separate dir, put it in portage's DEFAULT_PATH before /bin and /usr/bin and all would work perfectly well from the ebuild/eclass perspective. Fabian has summed it up nicely, thanks. i could care less what your userland is outside of the ebuild environment since it doesnt matter to ebuild writers. you want a deficient runtime environment, more power to you, but forcing that environment onto ebuild developers is not acceptable. off the top of my head, i'd like to see GNU find/xargs added to the ebuild environment. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
Mike Frysinger wrote: Fabian has summed it up nicely, thanks. i could care less what your userland is outside of the ebuild environment since it doesnt matter to ebuild writers. you want a deficient runtime environment, more power to you, but forcing that environment onto ebuild developers is not acceptable. off the top of my head, i'd like to see GNU find/xargs added to the ebuild environment. -mike Mike, exactly as I said. That's option #2, and I think it could be a great solution. As for deficient, well, that's in the eye of the beholder. ;) -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Joe Peterson wrote: Mike Frysinger wrote: wrong. bash and GNU prevail because they provide useful extensions. it may be worthwhile to force `find` in the portage environment to be GNU find so we can stop wasting time trying to figure out how to rewrite expressions in ebuilds (which can be done trivially with GNU) with a limited functionality set (such as POSIX). Shouldn't we do just the opposite? GNU find doesn't exist on all archs (BSD is an example). There was just an example of GNU extensions being used on find that broke on FreeBSD. It would be more portable to *avoid* GNU-only extensions in ebuilds. as mentioned, GNU is the main bread and butter of Gentoo. forcing the majority of people to go pure POSIX in the face of GNU extensions that make life easier is wrong. so the minority gets screwed, that's life. especially considering it's trivial for the minority to conform. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Wednesday 03 October 2007, Roy Marples wrote:
On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
Pattern matching can be done just as well with case. Infact, tend to
use [[ == ]] a lot when pattern matching when a case statement would be
more efficient and use less code. Of course when you're just interested
in matching one one thing in a code block then it uses more code, but
that is probably outside the norm.
case statements can be used in place of *some* statements, but not nearly
all and certainly does not provide the extended logic combining
capabilities. need to do boolean logic ? say hello to convoluted nested
case statements!
You can also do some pattern matching like so
foo=foo foobar
[ ${foo%foobar} = ${foo} ] || echo ends with foobar
[ ${foo#foobar} = ${foo} ] || echo starts with foo
[ ${foo#* } = ${foo} ] || echo has a space
So there's no need for convoluted nested case statements.
no need implies that everything can be done, but you started off
with some ... you're still going from one clean logic statement to multiple
ones where the nested logic gets to be a pita to track. again, this is a
sad/unacceptable solution.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
Pattern matching can be done just as well with case. Infact, tend to use
[[ == ]] a lot when pattern matching when a case statement would be more
efficient and use less code. Of course when you're just interested in
matching one one thing in a code block then it uses more code, but that
is probably outside the norm.
case statements can be used in place of *some* statements, but not nearly all
and certainly does not provide the extended logic combining capabilities.
need to do boolean logic ? say hello to convoluted nested case statements!
You can also do some pattern matching like so
foo=foo foobar
[ ${foo%foobar} = ${foo} ] || echo ends with foobar
[ ${foo#foobar} = ${foo} ] || echo starts with foo
[ ${foo#* } = ${foo} ] || echo has a space
So there's no need for convoluted nested case statements.
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Mon, 2007-10-01 at 20:22 -0400, Mike Frysinger wrote: better readability is a pretty subjective claim ... Many things are subjective - one mans good is another mans bad. /me shrugs i'd say that changing things from doing a case match against proper character classes to doing a printf against arbitrary character ranges (which btw are not locale safe, so i imagine you've introduced a regression there) is not better. but i'm not the maintainer of said eclass. That is why the case match is like so [0-9] Should be safe - every language should operate in base 10 -|.|_ Exact match * If it's not the above, treat it like a letter So there shouldn't be any regressions with version numbers here as I've cunningly avoided the locale trap. but I find interesting that you ripped Ciaran's copyright while leaving the Prod ciaranm if you find something it can't handle comment. I copied and pasted the comments for the most part. Sorry for leaving that bit in. And I thought that the Gentoo Foundation had the copyright? it does. and if it doesnt, punt the file and rewrite it from scratch. Well, this should constitute a rewrite from scratch. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Mon, 2007-10-01 at 23:30 +0100, Roy Marples wrote: On Monday 01 October 2007 22:59:40 Roy Marples wrote: This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. It should be noted that that first draft was developed on bash only. Attached is a patch that fixes quoting on all shells and shift errors on ash/dash/busybox variants. Reuseable code. Great! Also attached is the patched versionater.eclass again. After a quick look I wonder how/if it deals with: 1.01 1.1 -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 08:35 +0200, Natanael Copa wrote: After a quick look I wonder how/if it deals with: 1.01 1.1 It treats them the same way [EMAIL PROTECTED] ~ $ bash -c '. /usr/portage/eclass/versionator.eclass; version_compare 1.01 1.1; echo $?' 2 [EMAIL PROTECTED] ~ $ bash -c '. ./versionator.eclass; version_compare 1.01 1.1; echo $?' 2 I'm also glad you asked as spb claims my version is broken with repsect to this. I disagree as it matches the portage version. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On 01-10-2007 22:59:40 +0100, Roy Marples wrote: I would like to propse a new versionator.eclass for consideration (attached). This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? I personally like consistency. So if we use bash in ebuilds, then I'd like to use bash in eclasses too. I'm interested in your motivation to make this eclass pure sh, whatever that may mean. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote: On 01-10-2007 22:59:40 +0100, Roy Marples wrote: I would like to propse a new versionator.eclass for consideration (attached). This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? The bonus is that it works on shells other than bash. I personally like consistency. So if we use bash in ebuilds, then I'd like to use bash in eclasses too. I'm interested in your motivation to make this eclass pure sh, whatever that may mean. I like consistency too, and I'll be pushing for using sh instead of forcing bash. My motivation? Simple. I don't believe that the portage tree should be locked into using one shell. I believe that vendor lock-in should happen at the social level, not the technical one. portage itself was a lock-in until until PMS came about, now I'd like to remove the lock-in from the tree itself. This in itself is a good thing as we can pick and choose the tools we want to use as they're all playing on the same field. This same rationale applies to scriptlets outside portage tree use, such as revdep-rebuild [1]. It's more of a bashlet, but I've also demonstrated that there was no reason to force bash there. Obviously there are more lock-ins than just the shell, but it's a good start. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote: On 01-10-2007 22:59:40 +0100, Roy Marples wrote: I would like to propse a new versionator.eclass for consideration (attached). This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? I personally like consistency. So if we use bash in ebuilds, then I'd like to use bash in eclasses too. I'm interested in your motivation to make this eclass pure sh, whatever that may mean. Code is GPL. It can be reused. shell code that can compare versions is very attarctive. It can be used to write shellscripts that removes all tbz2 but the last version. It can be re-used in runtime-only environemnts. It can be reused on non-gentoo hosts hosting distfiles/tbz2. Or it can be reused in a binary only package manager like http://apk-tools.sf.net (yep, i reinveted the wheel there, just because my uclibc runtime environments dont include python) If it make sense to POSIX compliant shell code in any eclass, it would be version handling code. Thanks Roy! -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On 02-10-2007 09:48:06 +0100, Roy Marples wrote: What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? The bonus is that it works on shells other than bash. I give you a big chance Solaris' or AIX' /bin/sh won't grok this stuff. I personally like consistency. So if we use bash in ebuilds, then I'd like to use bash in eclasses too. I'm interested in your motivation to make this eclass pure sh, whatever that may mean. I like consistency too, and I'll be pushing for using sh instead of forcing bash. I admire your courage. My motivation? Simple. I don't believe that the portage tree should be locked into using one shell. I believe that vendor lock-in should happen vendor lock-in is an interesting term to mention here, as bash is open source, and I think (I'm not a lawyer) free to use as long as you want, and modifyable if you like. at the social level, not the technical one. portage itself was a lock-in until until PMS came about, now I'd like to remove the lock-in from the tree itself. This in itself is a good thing as we can pick and choose the tools we want to use as they're all playing on the same field. This same rationale applies to scriptlets outside portage tree use, such as revdep-rebuild [1]. It's more of a bashlet, but I've also demonstrated that there was no reason to force bash there. Obviously there are more lock-ins than just the shell, but it's a good start. Given my own history I have a hard time to believe you are persuing the right track here. It may or may not be a secret that I currently do the complete opposite of what you're trying to do -- so far with a good lot of success, especially given the number of completely different platforms. Question from me to you is, whether your vision is just to get (Free)BSD working seamlessly with Gentoo, or whether you also look beyond your current scope to the Meta Distribution. This includes the benefit of moving from bash to POSIX(?) sh as standard kit to interpret the meta information. Changing init.d scripts is one thing, changing the definition of how the meta information should be read is another thing. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: On Mon, 2007-10-01 at 20:22 -0400, Mike Frysinger wrote: i'd say that changing things from doing a case match against proper character classes to doing a printf against arbitrary character ranges (which btw are not locale safe, so i imagine you've introduced a regression there) is not better. but i'm not the maintainer of said eclass. That is why the case match is like so [0-9] Should be safe - every language should operate in base 10 -|.|_ Exact match * If it's not the above, treat it like a letter So there shouldn't be any regressions with version numbers here as I've cunningly avoided the locale trap. sorry, you're right ... i thought i saw a [A-Z] in there, but it was probably that the old one used [:alpha:] that said, there's no reason to change [[:digit:]] to [0-9] ... using proper character classes is preferred over custom rangers regardless -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 11:22 +0200, Fabian Groffen wrote: On 02-10-2007 09:48:06 +0100, Roy Marples wrote: What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? The bonus is that it works on shells other than bash. I give you a big chance Solaris' or AIX' /bin/sh won't grok this stuff. Neither claim to be posix shells either, or didn't last I looked. I say baselayout-2 works with any shell that claims posix. Of course, changing it to bash is a trivial matter also. My motivation? Simple. I don't believe that the portage tree should be locked into using one shell. I believe that vendor lock-in should happen vendor lock-in is an interesting term to mention here, as bash is open source, and I think (I'm not a lawyer) free to use as long as you want, and modifyable if you like. Just because it's open source does not mean that it won't try and lock you in. Given my own history I have a hard time to believe you are persuing the right track here. It may or may not be a secret that I currently do the complete opposite of what you're trying to do -- so far with a good lot of success, especially given the number of completely different platforms. Question from me to you is, whether your vision is just to get (Free)BSD working seamlessly with Gentoo, or whether you also look beyond your current scope to the Meta Distribution. This includes the benefit of moving from bash to POSIX(?) sh as standard kit to interpret the meta information. Changing init.d scripts is one thing, changing the definition of how the meta information should be read is another thing. A common parlance on Slashdot when referring to Microsoft is that monoculture is bad. Forcing bash and GNU tools down everyones throat is no better - it's just replacing one monoculture with another one. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On 02-10-2007 10:37:25 +0100, Roy Marples wrote: vendor lock-in is an interesting term to mention here, as bash is open source, and I think (I'm not a lawyer) free to use as long as you want, and modifyable if you like. Just because it's open source does not mean that it won't try and lock you in. as far as I'm aware it can't lock you in as in the original definition of the term lock-in, but I get your point, even though I disagree. Question from me to you is, whether your vision is just to get (Free)BSD working seamlessly with Gentoo, or whether you also look beyond your current scope to the Meta Distribution. This includes the benefit of moving from bash to POSIX(?) sh as standard kit to interpret the meta information. Changing init.d scripts is one thing, changing the definition of how the meta information should be read is another thing. A common parlance on Slashdot when referring to Microsoft is that monoculture is bad. Forcing bash and GNU tools down everyones throat is no better - it's just replacing one monoculture with another one. Which doesn't seem to be an answer to the question at all to me. My question was basically about what the benefits are of changing the meta information interpretation definition. In other words, if project X says their code should be compiled with GCC, what are the benefits exactly if you change that into should be compiled with a C99 compliant compiler, considering you are eventually interested in the produced code only. (Is it worth it to teach/force devs to use something else if this is only how to obtain the end product, which should run with anything?) -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: On Tue, 2007-10-02 at 09:29 +0200, Fabian Groffen wrote: On 01-10-2007 22:59:40 +0100, Roy Marples wrote: I would like to propse a new versionator.eclass for consideration (attached). This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. What is your rationale to say that pure sh is a bonus? Especially given the environment this is used in as ferdy already pointed out? The bonus is that it works on shells other than bash. which is irrelevant here I personally like consistency. So if we use bash in ebuilds, then I'd like to use bash in eclasses too. I'm interested in your motivation to make this eclass pure sh, whatever that may mean. I like consistency too, and I'll be pushing for using sh instead of forcing bash. pushing a new standard by slowly converting the tree is not the way to go. My motivation? Simple. I don't believe that the portage tree should be locked into using one shell. I believe that vendor lock-in should happen at the social level, not the technical one. portage itself was a lock-in until until PMS came about, now I'd like to remove the lock-in from the tree itself. This in itself is a good thing as we can pick and choose the tools we want to use as they're all playing on the same field. POSIX lacks useful bash extensions that are used heavily ... arrays, string replacements, pattern matching with [[ == ]] to name some. here's your technical reason for using the bash standard over POSIX: it's superior. This same rationale applies to scriptlets outside portage tree use, such as revdep-rebuild [1]. It's more of a bashlet, but I've also demonstrated that there was no reason to force bash there. not really ... there's a reason the environment dictated inside of the package manager requires GNU stuff ... the extensions provided make life easy. all this conversion from trivial GNU extensions to limited POSIX interfaces is a pita (as can trivially be seen with find and xargs). as for no reason, just because it can be done differently doesnt mean it should. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 11:49 +0200, Fabian Groffen wrote: Which doesn't seem to be an answer to the question at all to me. My question was basically about what the benefits are of changing the meta information interpretation definition. In other words, if project X says their code should be compiled with GCC, what are the benefits exactly if you change that into should be compiled with a C99 compliant compiler, considering you are eventually interested in the produced code only. (Is it worth it to teach/force devs to use something else if this is only how to obtain the end product, which should run with anything?) project X says their code should be compiled with GCC, should we deny the ICC users the ability to compile it? I don't think so. I think users should have a choice. If users didn't have choice, then EGCS would never have happened. I believe it is work teaching devs to use POSIX shell over bash. For example, many of the recent commits have highlighted that a lot of devs have no idea when it comes to quoting. My view on this is because bash encourages you not to quote by using [[ ]], unlike POSIX [ ] which forces you to know when to quote. It also means that their code stands a better chance of working where bash is not available, but /bin/sh is a POSIX shell still. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: A common parlance on Slashdot when referring to Microsoft is that monoculture is bad. Forcing bash and GNU tools down everyones throat is no better - it's just replacing one monoculture with another one. wrong. bash and GNU prevail because they provide useful extensions. it may be worthwhile to force `find` in the portage environment to be GNU find so we can stop wasting time trying to figure out how to rewrite expressions in ebuilds (which can be done trivially with GNU) with a limited functionality set (such as POSIX). i may also point out that many GNU extensions get codified in POSIX over time ... why ? because *they are useful*. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote:
The bonus is that it works on shells other than bash.
which is irrelevant here
I think otherwise.
I personally like consistency. So if we use bash in ebuilds, then I'd
like to use bash in eclasses too. I'm interested in your motivation to
make this eclass pure sh, whatever that may mean.
I like consistency too, and I'll be pushing for using sh instead of
forcing bash.
pushing a new standard by slowly converting the tree is not the way to go.
That's why I'm here talking, trying to convince people. Some people like
yourself will never be convinced though.
POSIX lacks useful bash extensions that are used heavily ... arrays, string
replacements, pattern matching with [[ == ]] to name some. here's
your technical reason for using the bash standard over POSIX: it's
superior.
POSIX has positional parameters, which provide array like functionality.
I would argue that this is better as you cannot pass an array to a
function - you have to pass it as positional parameters.
I agree that the bash array is superior as you can grab the index of
items =10 easily and walk it backwards, but I've yet to see a case
where it cannot be done otherwise.
Pattern matching can be done just as well with case. Infact, tend to use
[[ == ]] a lot when pattern matching when a case statement would be more
efficient and use less code. Of course when you're just interested in
matching one one thing in a code block then it uses more code, but that
is probably outside the norm.
String replacements. This is the real bug bear isn't it? sh has no easy
answer to this, but that doesn't mean that we can't use it. We use many
eclass specific functions, so why not have another?
foo=${haystack//needle/thread}
foo=$(ereplace ${haystack} ${needle} ${thread})
I already have sh code that handles that as we can't call external bins
in global scope for ebuilds. But for everything else there's sed.
This same rationale applies to scriptlets outside portage tree use, such
as revdep-rebuild [1]. It's more of a bashlet, but I've also
demonstrated that there was no reason to force bash there.
not really ... there's a reason the environment dictated inside of the
package
manager requires GNU stuff ... the extensions provided make life easy. all
this conversion from trivial GNU extensions to limited POSIX interfaces is a
pita (as can trivially be seen with find and xargs). as for no reason,
just because it can be done differently doesnt mean it should.
Using the same argument, just because there is a GNU extension does not
mean it should be used.
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: On Tue, 2007-10-02 at 11:49 +0200, Fabian Groffen wrote: Which doesn't seem to be an answer to the question at all to me. My question was basically about what the benefits are of changing the meta information interpretation definition. In other words, if project X says their code should be compiled with GCC, what are the benefits exactly if you change that into should be compiled with a C99 compliant compiler, considering you are eventually interested in the produced code only. (Is it worth it to teach/force devs to use something else if this is only how to obtain the end product, which should run with anything?) project X says their code should be compiled with GCC, should we deny the ICC users the ability to compile it? that is project X's decision and no one else's. dont pull a stallman on us and force everyone to subscribe to your ideas of freedom. there's a reason we told him to take a hike. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 06:10 -0400, Mike Frysinger wrote: On Tuesday 02 October 2007, Roy Marples wrote: A common parlance on Slashdot when referring to Microsoft is that monoculture is bad. Forcing bash and GNU tools down everyones throat is no better - it's just replacing one monoculture with another one. wrong. bash and GNU prevail because they provide useful extensions. it may be worthwhile to force `find` in the portage environment to be GNU find so we can stop wasting time trying to figure out how to rewrite expressions in ebuilds (which can be done trivially with GNU) with a limited functionality set (such as POSIX). BSD find also has the similar extensions, just implemented differently. i may also point out that many GNU extensions get codified in POSIX over time ... why ? because *they are useful*. By the same token I should be able to use BSD extensions if said program also works on Linux. Also, BSD extensions get codified in POSIX also. My understanding is that a lot of POSIX is based on BSD4. Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On 02-10-2007 11:09:21 +0100, Roy Marples wrote: It also means that their code stands a better chance of working where bash is not available, but /bin/sh is a POSIX shell still. I prefer to define that ebuilds (and eclasses) are dealt by GNU bash, which is installed as part of the installation ritual for a Gentoo/X system. I also prefer to define that all common tools ebuilds and eclasses use such as cp, rm, awk, sed, find, xargs are GNU variants, installed as part of the same installation ritual for a Gentoo/X system. With such definition, a Gentoo/X system without bash cannot exist. What you use outside of the Gentoo build/package manager environment is completely up to you. Rationale: All tools (bash, coreutils, findutils, sed, gawk) can be compiled and installed on any system I know of. Their use is widespread and accepted. Our primary group of people working on ebuilds and eclasses (Gentoo developers) work on a Gentoo system having said tools (and only those) installed, making it a logical choice. I personally fail to see the advantage of using portable or standards compliant code here over what we have currently. We don't force it down on anyone, we only use it to install a package for you. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: On Tue, 2007-10-02 at 06:10 -0400, Mike Frysinger wrote: On Tuesday 02 October 2007, Roy Marples wrote: A common parlance on Slashdot when referring to Microsoft is that monoculture is bad. Forcing bash and GNU tools down everyones throat is no better - it's just replacing one monoculture with another one. wrong. bash and GNU prevail because they provide useful extensions. it may be worthwhile to force `find` in the portage environment to be GNU find so we can stop wasting time trying to figure out how to rewrite expressions in ebuilds (which can be done trivially with GNU) with a limited functionality set (such as POSIX). BSD find also has the similar extensions, just implemented differently. i may also point out that many GNU extensions get codified in POSIX over time ... why ? because *they are useful*. By the same token I should be able to use BSD extensions if said program also works on Linux. Also, BSD extensions get codified in POSIX also. My understanding is that a lot of POSIX is based on BSD4. BSD is a second class citizen to GNU here. Gentoo started out as a project targetting a GNU userland under Linux and will continue for quite sometime (forever?) as the majority/core focus. forcing the project to limit itself when there is no gain (yet plenty of pain) for the majority of users is a no brainer: no. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 06:28 -0400, Mike Frysinger wrote: project X says their code should be compiled with GCC, should we deny the ICC users the ability to compile it? that is project X's decision and no one else's. dont pull a stallman on us and force everyone to subscribe to your ideas of freedom. there's a reason we told him to take a hike. We change upstream decisions all the time via patches and USE flags when we as developers think that it could be done better, to make it fit into our file layout. Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote:
On Tue, 2007-10-02 at 05:39 -0400, Mike Frysinger wrote:
I personally like consistency. So if we use bash in ebuilds, then
I'd like to use bash in eclasses too. I'm interested in your
motivation to make this eclass pure sh, whatever that may mean.
I like consistency too, and I'll be pushing for using sh instead of
forcing bash.
pushing a new standard by slowly converting the tree is not the way to
go.
That's why I'm here talking, trying to convince people. Some people like
yourself will never be convinced though.
i am convinced by superior standards and by good things. forcing the standard
from bash to POSIX is neither of these. i dont see that as a flaw in my
logic.
POSIX lacks useful bash extensions that are used heavily ... arrays,
string replacements, pattern matching with [[ == ]] to name some. here's
your technical reason for using the bash standard over POSIX: it's
superior.
POSIX has positional parameters, which provide array like functionality.
I would argue that this is better as you cannot pass an array to a
function - you have to pass it as positional parameters.
having the option leads to better code. sometimes positional parameter usage
is a better idea, sometimes it is not.
I agree that the bash array is superior as you can grab the index of
items =10 easily and walk it backwards, but I've yet to see a case
where it cannot be done otherwise.
positional parameters provide a workaround for *1* array. what if you need
two ? three ? well damn, you're pickled in the pooper i think.
Pattern matching can be done just as well with case. Infact, tend to use
[[ == ]] a lot when pattern matching when a case statement would be more
efficient and use less code. Of course when you're just interested in
matching one one thing in a code block then it uses more code, but that
is probably outside the norm.
case statements can be used in place of *some* statements, but not nearly all
and certainly does not provide the extended logic combining capabilities.
need to do boolean logic ? say hello to convoluted nested case statements!
String replacements. This is the real bug bear isn't it? sh has no easy
answer to this, but that doesn't mean that we can't use it. We use many
eclass specific functions, so why not have another?
foo=${haystack//needle/thread}
foo=$(ereplace ${haystack} ${needle} ${thread})
I already have sh code that handles that as we can't call external bins
in global scope for ebuilds. But for everything else there's sed.
i dont buy either of these as solutions but workarounds. workarounds
get punted for solutions.
This same rationale applies to scriptlets outside portage tree use,
such as revdep-rebuild [1]. It's more of a bashlet, but I've also
demonstrated that there was no reason to force bash there.
not really ... there's a reason the environment dictated inside of the
package manager requires GNU stuff ... the extensions provided make life
easy. all this conversion from trivial GNU extensions to limited POSIX
interfaces is a pita (as can trivially be seen with find and xargs). as
for no reason, just because it can be done differently doesnt mean it
should.
Using the same argument, just because there is a GNU extension does not
mean it should be used.
yes it does. here's the scenario: use 1 find statement that is clear and
concise (but requires a GNU extension) or chain 1 find statement into
multiple other programs and combine it with shell code. you get the same
result, but the former is a ton easier to maintain. bogus scenario you say ?
i just dealt with it.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: On Tue, 2007-10-02 at 06:28 -0400, Mike Frysinger wrote: project X says their code should be compiled with GCC, should we deny the ICC users the ability to compile it? that is project X's decision and no one else's. dont pull a stallman on us and force everyone to subscribe to your ideas of freedom. there's a reason we told him to take a hike. We change upstream decisions all the time via patches and USE flags when we as developers think that it could be done better, to make it fit into our file layout. some people (because it's in *their* interest to do so) have the option of maintaining changes. that does not mean anyone is required to do so. glibc for example provides no support unless you build it with gcc. so how does icc build it ? they implement the *useful* GNU extensions. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On 02-10-2007 12:00:12 +0100, Roy Marples wrote: Infact, if we're not interested in portable code why bother with Gentoo/ALT in the first place? Our code /IS/ portable, that's why you and me have a working Gentoo/Alt system at the moment. -- Fabian Groffen Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
i am convinced by superior standards and by good things. forcing the
standard
from bash to POSIX is neither of these. i dont see that as a flaw in my
logic.
Forcing? I'm not asking for anything to be forced, I'm asking for it to
be allowed.
By the same token, I don't force anyone to write a sh init script and I
allow bash init scripts in baselayout.
positional parameters provide a workaround for *1* array. what if you need
two ? three ? well damn, you're pickled in the pooper i think.
Not exactly true, you can use multi dimensional arrays through eval
usage. Nasty I know, but I think the same thing about arrays like so
anyway.
Pattern matching can be done just as well with case. Infact, tend to use
[[ == ]] a lot when pattern matching when a case statement would be more
efficient and use less code. Of course when you're just interested in
matching one one thing in a code block then it uses more code, but that
is probably outside the norm.
case statements can be used in place of *some* statements, but not nearly all
and certainly does not provide the extended logic combining capabilities.
need to do boolean logic ? say hello to convoluted nested case statements!
Then variables should be used to make the code readable.
String replacements. This is the real bug bear isn't it? sh has no easy
answer to this, but that doesn't mean that we can't use it. We use many
eclass specific functions, so why not have another?
foo=${haystack//needle/thread}
foo=$(ereplace ${haystack} ${needle} ${thread})
I already have sh code that handles that as we can't call external bins
in global scope for ebuilds. But for everything else there's sed.
i dont buy either of these as solutions but workarounds. workarounds
get punted for solutions.
By the same token, epatch is a workaround to apply non exact patches.
The correct solution is to craft an exact patch. So we should punt
epatch too?
This same rationale applies to scriptlets outside portage tree use,
such as revdep-rebuild [1]. It's more of a bashlet, but I've also
demonstrated that there was no reason to force bash there.
not really ... there's a reason the environment dictated inside of the
package manager requires GNU stuff ... the extensions provided make life
easy. all this conversion from trivial GNU extensions to limited POSIX
interfaces is a pita (as can trivially be seen with find and xargs). as
for no reason, just because it can be done differently doesnt mean it
should.
Using the same argument, just because there is a GNU extension does not
mean it should be used.
yes it does. here's the scenario: use 1 find statement that is clear and
concise (but requires a GNU extension) or chain 1 find statement into
multiple other programs and combine it with shell code. you get the same
result, but the former is a ton easier to maintain. bogus scenario you say ?
i just dealt with it.
Let me guess - openssl?
Thanks
Roy
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
Roy Marples wrote: Well, let me be the first to stand for equal rights then! Hm... I say that for the most part, there should be no technical reason why ebuilds cannot be in posix shell whilst being readable and maintainable. Beside teaching us how to do that. If portage or another package manager wishes to uses bash to parse ebuilds and eclasses, more power to them! I won't stop that. I just want the ability for other shells to do the same. It isn't hard, and you don't need to be a rocket scientist. It's not an overnight change, but a gradual change. I'm more radical, what if I want to have my package manager parse ebuilds w/out needing outside shell but a custom tailed parser (because of performance)? Nothing prevents to implement the parser from scratch in both cases... IFF your proposed changes lead to something that is simpler or as simple to write, faster or as fast to parse, easier or as easy to read/maintain; then you may have a solid stance. Otherwise it is a pointless annoyance for everybody, you first, us second. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote:
On Tue, 2007-10-02 at 06:57 -0400, Mike Frysinger wrote:
i am convinced by superior standards and by good things. forcing the
standard from bash to POSIX is neither of these. i dont see that as a
flaw in my logic.
Forcing? I'm not asking for anything to be forced, I'm asking for it to
be allowed.
it already is allowed. bash is a superset of POSIX so anything that can be
done in POSIX can be done in bash. if you arent after changing the shell
standard inside of ebuilds to POSIX, then this discussion is moot. keep it
all bash so things remain consistent and we're done.
positional parameters provide a workaround for *1* array. what if you
need two ? three ? well damn, you're pickled in the pooper i think.
Not exactly true, you can use multi dimensional arrays through eval
usage. Nasty I know, but I think the same thing about arrays like so
anyway.
i'm fully aware of all the nested hacks that can be done with eval. that is
not an acceptable answer.
Pattern matching can be done just as well with case. Infact, tend to
use [[ == ]] a lot when pattern matching when a case statement would be
more efficient and use less code. Of course when you're just interested
in matching one one thing in a code block then it uses more code, but
that is probably outside the norm.
case statements can be used in place of *some* statements, but not nearly
all and certainly does not provide the extended logic combining
capabilities. need to do boolean logic ? say hello to convoluted nested
case statements!
Then variables should be used to make the code readable.
so you'd advocate dropping one perfectly readable/understandable line of code
for multiple lines of variables/case statements ? that doesnt make sense.
String replacements. This is the real bug bear isn't it? sh has no easy
answer to this, but that doesn't mean that we can't use it. We use many
eclass specific functions, so why not have another?
foo=${haystack//needle/thread}
foo=$(ereplace ${haystack} ${needle} ${thread})
I already have sh code that handles that as we can't call external bins
in global scope for ebuilds. But for everything else there's sed.
i dont buy either of these as solutions but workarounds.
workarounds get punted for solutions.
By the same token, epatch is a workaround to apply non exact patches.
The correct solution is to craft an exact patch. So we should punt
epatch too?
these things are not equivalent by any means. epatch provides a consistent
interface (both for ebuild writers and users) to apply patches where there
was none ... this gave us reliable behavior across the board in terms of how
patches were fed in, applied to the source, and errors were handled as well
as the output from the process (status messages and helpful debug information
from failures) ... the fact that epatch attempts with different -p# levels is
an extension to automate a step that is 99% of the time irrelevant to the
final result. these topics do not pertain to string replacements.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Roy Marples wrote: On Tue, 2007-10-02 at 06:49 -0400, Mike Frysinger wrote: BSD is a second class citizen to GNU here. Gentoo started out as a project targetting a GNU userland under Linux and will continue for quite sometime (forever?) as the majority/core focus. forcing the project to limit itself when there is no gain (yet plenty of pain) for the majority of users is a no brainer: no. Well, let me be the first to stand for equal rights then! equal rights lose when the minority causes undue support burdens on the majority, especially when there's simple ways for the minorties to conform. Anyway, this was about changing the portage tree syntax from bash to posix shell, not gnu vs bsd vs userland tools. The arguments are not the same as bash supports posix shell whereas gnu tools don't support bsd extensions and bsd tools don't support gnu extensions. it is the same argument. you're proposing technically inferior solutions for no gain whatsoever to the majority of people. I say that for the most part, there should be no technical reason why ebuilds cannot be in posix shell whilst being readable and maintainable. the devils in the details isnt it. i've already mentioned deficiencies in the POSIX syntax when compared to bash which is commonly used. if the POSIX standard cannot satisfy the entire tree, then there's no point in converting subsets -- you lead to ugly inconsistencies which can be very confusing for people who dont live breathe eat poop eat some more this crap every day (which i'd wager is pretty much everyone in Gentoo), nor do i think this should be a hard requirement. you and i and a very small handful of other people are irrelevant drops in the Gentoo bucket. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Luca Barbato wrote: IFF your proposed changes lead to something that is simpler or as simple to write, faster or as fast to parse, easier or as easy to read/maintain; then you may have a solid stance. Otherwise it is a pointless annoyance for everybody, you first, us second. in the general case, dash will typically parse faster than bash. but is this speed gain relevant ? if dash can parse an ebuild in 10% of the time that it takes bash, but bash can do it in a 1 second, do we care ? the majority of ebuilds are going to take magnitudes larger to get the job done (running ./configure make). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On 10/2/07, Roy Marples [EMAIL PROTECTED] wrote: On Tue, 2007-10-02 at 06:49 -0400, Mike Frysinger wrote: BSD is a second class citizen to GNU here. Gentoo started out as a project targetting a GNU userland under Linux and will continue for quite sometime (forever?) as the majority/core focus. forcing the project to limit itself when there is no gain (yet plenty of pain) for the majority of users is a no brainer: no. Well, let me be the first to stand for equal rights then! So there is a difference I think between 'making stuff work on BSD' and 'changing the fundamental requirements of the distribution'. Anyway, this was about changing the portage tree syntax from bash to posix shell, not gnu vs bsd vs userland tools. The arguments are not the same as bash supports posix shell whereas gnu tools don't support bsd extensions and bsd tools don't support gnu extensions. I say that for the most part, there should be no technical reason why ebuilds cannot be in posix shell whilst being readable and maintainable. There is no technical reason. But if you think for two seconds this is only a technical problem then I think you have not examined it properly. Most of the developers here are running GNU/linux with GNU tools (as has been pointed out). These are the tools that are used and there is no gain *for them* to write in what I can only gather as an inferior but portable sh syntax. They would be writing for sh only to satisfy you, and you have IMHO done a poor job of motivating them. You can put bash in baselayout in BSD in like 2 seconds and prevent all this hard work you are asking of other developers. Personally, I like your idea in general until I have to start writing ebuilds in sh, and init scripts in sh, and pretty much anything in sh; as vapier points out, sh sucks donkey balls. So I *will* use bash, because the fix is 'gentoo requires bash', it's always required bash, and you haven't convinced me that it should change. Unless there is some crazy ass reason why you can't install bash on a given platform, I don't think there is a technical reason to avoid using bash. If portage or another package manager wishes to uses bash to parse ebuilds and eclasses, more power to them! I won't stop that. I just want the ability for other shells to do the same. It isn't hard, and you don't need to be a rocket scientist. It's not an overnight change, but a gradual change. Thanks Roy -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
Mike Frysinger wrote: in the general case, dash will typically parse faster than bash. but is this speed gain relevant ? if dash can parse an ebuild in 10% of the time that it takes bash, but bash can do it in a 1 second, do we care ? the majority of ebuilds are going to take magnitudes larger to get the job done (running ./configure make). You may want to parse an ebuild not just for building it ^^ still my point is that if the alternative isn't better isn't interesting =/ lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tuesday 02 October 2007, Luca Barbato wrote: Mike Frysinger wrote: in the general case, dash will typically parse faster than bash. but is this speed gain relevant ? if dash can parse an ebuild in 10% of the time that it takes bash, but bash can do it in a 1 second, do we care ? the majority of ebuilds are going to take magnitudes larger to get the job done (running ./configure make). You may want to parse an ebuild not just for building it ^^ true ... but i'd have to wonder if there's anything worth parsing out that the pregenerated metadata does not provide for you ... i guess if you want to parse an ebuild that isnt in the tree thus lacks metadata ... but we further marginalize the use ... -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 05:39 -0700, Alec Warner wrote: I don't think there is a technical reason to avoid using bash. Ofcourse there is. See first issue mentioned in BUGS section in bash manpage. -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 09:26 -0400, Mike Frysinger wrote: On Tuesday 02 October 2007, Luca Barbato wrote: Mike Frysinger wrote: in the general case, dash will typically parse faster than bash. but is this speed gain relevant ? if dash can parse an ebuild in 10% of the time that it takes bash, but bash can do it in a 1 second, do we care ? the majority of ebuilds are going to take magnitudes larger to get the job done (running ./configure make). You may want to parse an ebuild not just for building it ^^ true ... but i'd have to wonder if there's anything worth parsing out that the pregenerated metadata does not provide for you ... pkg_* and stuff that binary package managers needs. Things that creates user accounts etc. I would actually prefer getting that stuff into metadata. It would open up new doors for binary only package managers. i guess if you want to parse an ebuild that isnt in the tree thus lacks metadata ... but we further marginalize the use ... -mike -nc -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Natanael Copa wrote: On Tue, 2007-10-02 at 05:39 -0700, Alec Warner wrote: I don't think there is a technical reason to avoid using bash. Ofcourse there is. See first issue mentioned in BUGS section in bash manpage. Presumably these bugs don't impact gentoo or we'd already be working around them. I don't see an issue with having bash as a gentoo dependency. Users don't have to use it as their primary shell - they just need to have it installed. I probably wouldn't use python at all if it weren't for portage, but I'm not complaining about migrating that. Now, if there were some gentoo target platform for which bash wasn't available maybe that would be a different issue - or if we were talking about some huge package that consumed tons of ram/space/etc. However, nobody is going to run gentoo on an embedded system (unless they build the system and then prune out the toolchain - in which case rm /bin/bash is pretty simple to do). Don't get me wrong - I would prefer that gentoo support more choices more officially (paludis comes to mind). However, that doesn't mean that we need to support choices that don't provide significant benefits. Now, if a posix-clean herd wants to take on the work of retooling stuff to be posixly-correct then perhaps we might ask other devs to be nice to them and accommodate their changes. However, that is a bit different than asking all the devs to use syntax that perhaps they're less than familiar with. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHAmVfG4/rWKZmVWkRAnlLAJ4noZkumP5prEofYtRDFyhYruPMIACgj2ZM lpaA2Ky4AdC3fTyL7AzBmfU= =qvmS -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] RFC: sh versionator.eclass
Mike Frysinger wrote: wrong. bash and GNU prevail because they provide useful extensions. it may be worthwhile to force `find` in the portage environment to be GNU find so we can stop wasting time trying to figure out how to rewrite expressions in ebuilds (which can be done trivially with GNU) with a limited functionality set (such as POSIX). Shouldn't we do just the opposite? GNU find doesn't exist on all archs (BSD is an example). There was just an example of GNU extensions being used on find that broke on FreeBSD. It would be more portable to *avoid* GNU-only extensions in ebuilds. -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Tue, 2007-10-02 at 17:02 -0600, Joe Peterson wrote: Mike Frysinger wrote: wrong. bash and GNU prevail because they provide useful extensions. it may be worthwhile to force `find` in the portage environment to be GNU find so we can stop wasting time trying to figure out how to rewrite expressions in ebuilds (which can be done trivially with GNU) with a limited functionality set (such as POSIX). Shouldn't we do just the opposite? GNU find doesn't exist on all archs (BSD is an example). There was just an example of GNU extensions being used on find that broke on FreeBSD. It would be more portable to *avoid* GNU-only extensions in ebuilds. I would argue that both are hackish workarounds and the correct solution is to get upstream to accept patches so that we shouldn't need to use funky find extensions, BSD or otherwise. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Monday 01 October 2007 22:59:40 Roy Marples wrote:
This version, I believe, is more readable and maintainable then the one
currently in portage. It also uses a lot less code and has the bonus of
being pure sh.
It should be noted that that first draft was developed on bash only.
Attached is a patch that fixes quoting on all shells and shift errors on
ash/dash/busybox variants.
Also attached is the patched versionater.eclass again.
Thanks
Roy
# Copyright 2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# sh version of versionator.eclass
# get_last_version_component_index implementation is not implemented because
# 1) The name encourages the use of bash arrarys
# 2) User could do $(($(get_version_component_count) - 1)) to achieve the
#same result
_get_all_version_components() {
local dosep=$1 ver=${2:-${PV}} x= last= this=
while [ -n ${ver} ]; do
x=$(printf %c ${ver})
case ${x} in
[0-9]) this=digit;;
-|.|_) this=sep;;
*) this=alpha;;
esac
if ${dosep} || [ ${this} != sep ]; then
[ -n ${last} -a ${this} != ${last} ] printf
printf %c ${x}
fi
last=${this}
ver=${ver#${x}}
done
}
# Split up a version string into its component parts. If no parameter is
# supplied, defaults to $PV.
# 0.8.3 - 0 . 8 . 3
# 7c - 7 c
# 3.0_p2 - 3 . 0 _ p2
# 20040905- 20040905
# 3.0c-r1 - 3 . 0 c - r1
get_all_version_components() {
_get_all_version_components true $@
}
# Get the important version components, excluding '.', '-' and '_'. Defaults to
# $PV if no parameter is supplied.
# 0.8.3 - 0 8 3
# 7c - 7 c
# 3.0_p2 - 3 0 p2
# 20040905- 20040905
# 3.0c-r1 - 3 0 c r1
get_version_components() {
_get_all_version_components false $@
}
# Get the major version of a value. Defaults to $PV if no parameter is supplied.
# 0.8.3 - 0
# 7c - 7
# 3.0_p2 - 3
# 20040905- 20040905
# 3.0c-r1 - 3
get_major_version() {
set -- $(get_version_components $@)
printf %s $1
}
# Get everything after the major version and its separator (if present) of a
# value. Defaults to $PV if no parameter is supplied.
# 0.8.3 - 8.3
# 7c - c
# 3.0_p2 - 0_p2
# 20040905- (empty string)
# 3.0c-r1 - 0c-r1
get_after_major_version() {
printf %s [EMAIL PROTECTED](get_major_version $@)}
}
_replace_version_separator_n() {
local n=$1 sep=$2 i=0
set -- $(get_all_version_components $3)
while [ -n $1 ]; do
case $1 in
-|.|_)
i=$((${i} + 1))
if [ ${i} = ${n} ]; then
printf %s ${sep}
else
printf %s $1
fi
;;
*)
printf %s $1
;;
esac
shift
done
}
_replace_version_separator_a() {
local n=$1 sep=$2 i=0
set -- $(get_all_version_components $3)
while [ -n $1 ]; do
if [ ${n} = $1 ]; then
printf %s ${sep}
n=
else
printf %s $1
fi
shift
done
}
# Replace the $1th separator with $2 in $3 (defaults to $PV if $3 is not
# supplied). If there are fewer than $1 separators, don't change anything.
# 1 '_' 1.2.3 - 1_2.3
# 2 '_' 1.2.3 - 1.2_3
# 1 '_' 1b-2.3 - 1b_2.3
# Rather than being a number, $1 can be a separator character such as '-', '.'
# or '_'. In this case, the first separator of this kind is selected.
replace_version_separator() {
case $1 in
[0-9]*) _replace_version_separator_n $@;;
*) _replace_version_separator_a $@;;
esac
}
# Replace all version separators in $2 (defaults to $PV) with $1.
# '_' 1b.2.3- 1b_2_3
replace_all_version_separators() {
local sep=$1
set -- $(get_all_version_components $2)
while [ -n $1 ]; do
case $1 in
-|.|_) printf %s ${sep};;
*) printf %s $1;;
esac
shift
done
}
# Delete the $1th separator in $2 (defaults to $PV if $2 is not supplied). If
# there are fewer than $1 separators, don't change anything.
# 1 1.2.3 - 12.3
# 2 1.2.3 - 1.23
# 1 1b-2.3 - 1b2.3
# Rather than
Re: [gentoo-dev] RFC: sh versionator.eclass
On Mon, Oct 01, 2007 at 11:30:16PM +0100, Roy Marples wrote: On Monday 01 October 2007 22:59:40 Roy Marples wrote: This version, I believe, is more readable and maintainable then the one currently in portage. It also uses a lot less code and has the bonus of being pure sh. It should be noted that that first draft was developed on bash only. Attached is a patch that fixes quoting on all shells and shift errors on ash/dash/busybox variants. Also attached is the patched versionater.eclass again. Thanks I sure as hell am not going to proof read all that (mainly because I think not using bash features in an environment where bash is required is silly, instead of being an improvement) but I find interesting that you ripped Ciaran's copyright while leaving the Prod ciaranm if you find something it can't handle comment. - ferdy -- Fernando J. Pereda GarcimartÃn 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpxTtGi7nili.pgp Description: PGP signature
Re: [gentoo-dev] RFC: sh versionator.eclass
On Monday 01 October 2007 23:41:36 Fernando J. Pereda wrote: I sure as hell am not going to proof read all that (mainly because I think not using bash features in an environment where bash is required is silly, instead of being an improvement) OK. Maybe I shouldn't have mentioned the in sh bit. If I re-submit stuff and just claim better readability and less code you'll read it then? but I find interesting that you ripped Ciaran's copyright while leaving the Prod ciaranm if you find something it can't handle comment. I copied and pasted the comments for the most part. Sorry for leaving that bit in. And I thought that the Gentoo Foundation had the copyright? Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: sh versionator.eclass
On Monday 01 October 2007, Roy Marples wrote: On Monday 01 October 2007 23:41:36 Fernando J. Pereda wrote: I sure as hell am not going to proof read all that (mainly because I think not using bash features in an environment where bash is required is silly, instead of being an improvement) OK. Maybe I shouldn't have mentioned the in sh bit. If I re-submit stuff and just claim better readability and less code you'll read it then? better readability is a pretty subjective claim ... i'd say that changing things from doing a case match against proper character classes to doing a printf against arbitrary character ranges (which btw are not locale safe, so i imagine you've introduced a regression there) is not better. but i'm not the maintainer of said eclass. but I find interesting that you ripped Ciaran's copyright while leaving the Prod ciaranm if you find something it can't handle comment. I copied and pasted the comments for the most part. Sorry for leaving that bit in. And I thought that the Gentoo Foundation had the copyright? it does. and if it doesnt, punt the file and rewrite it from scratch. -mike signature.asc Description: This is a digitally signed message part.
