[gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
Hi,
Mike Frysinger vap...@gentoo.org:
btw, latest python.eclass requires bash-3.2+ due to parsing errors in
the regex checks:
$ bash-3.1 -c '[[ a =~ ^(a|b)$ ]]'
bash-3.1: -c: line 0: syntax error in conditional expression:
unexpected token `(' bash-3.1: -c: line 0: syntax error near `^(a'
we could quote these or require bash-3.2+ ...
We discussed it briefly on the -pms mailing list [1].
V-Li
[1]http://archives.gentoo.org/gentoo-pms/msg_f4fee4c3a79ae4f37eaf4c4ebce6aafe.xml
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://gentoo.faulhammer.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
On 20-12-2008 05:35:25 +, Steve Long wrote: I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 requires at least that version (only unstable on mips as against 2.1.1-r2) It might be worth skipping to 3.2, since that would simplify regex handling. The only problem we have there is that bash-3.2.17 only comes in patches on top of 3.2. During bootstrap that's problematic, as gnu patch (or any other patch) might not be available, or simply b0rked. For that reason we bootstrap with a portage pre SVN revision 10460, which does not require =3.2.17. See http://bugs.gentoo.org/show_bug.cgi?id=229677#c11 on why PMS should require 3.2.17 over plain 3.2 if you decide to push the requirement update. We can work around it by using a self-made pre-patched tarball, though. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
On Sat, 20 Dec 2008 05:35:25 + Steve Long sl...@rathaus.eclipse.co.uk wrote: I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 requires at least that version (only unstable on mips as against 2.1.1-r2) It might be worth skipping to 3.2, since that would simplify regex handling. Stable isn't the measure. Stages are. Read the original email carefully and you shall see why. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: bash version in ebuilds/eclasses...non-compliance and what to do?
Jeremy Olexa wrote: This causes me pain on my hosts that don't have =bash-3.1[0] for /bin/bash. Because I can't install portage with an old bash until I get a new python installed which uses python.eclass which isn't supported with my /bin/bash (quite circular indeed) Technically there are workarounds for me...but it is still annoying. So...what do we do? A) Specifically allow =bash-3.1 features in ebuilds/eclasses. or B) revert the commit because the PMS says[1] that we comply with bash-3.0 Please discuss, thanks. I'd vote for updating the spec; it's going to be a pita trying to maintain the tree without +=. From our discussion, you said it was fine for prefix to specify a minimum version of bash for bootstrap, but clearly that can't be 3.1 when the draft PMS says 3.0. I note that bash-3.2_p17-r1 is stable on all the architectures that 3.0-r12 lists (it just adds the two -fbsd archs as unstable.) portage-2.1.4.5 requires at least that version (only unstable on mips as against 2.1.1-r2) It might be worth skipping to 3.2, since that would simplify regex handling. Not sure how that should be framed, or when it's okay to do it; clearly a spec has to be updatable, whether it's by a specified policy, or explicitly.
