| Summary: | [Future EAPI] Allow bash-4.2 features | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Arfrever Frehtes Taifersar Arahesis <arfrever.fta> |
| Component: | PMS/EAPI | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | esigra, hasufell, pacho, yac, yngwin |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=636652 | ||
| Whiteboard: | in-eapi-6 | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380, 414811, 463822 | ||
|
Description
Arfrever Frehtes Taifersar Arahesis
2012-08-14 07:10:40 UTC
This depends on EAPI parsing and can be implemented after a transition period has passed. EAPI parsing was introduced with portage-2.1.10.58. First stable version after this is portage-2.1.10.65, which was marked stable (for the last architecture) on 2012-07-01. The transition period starts at that date. I think we could nominate this for EAPI 6. Few notes: - there's no stable bash version between 3.1 and 4.2, - it's better to go for 4.2 since that would delay the necessity of bumping the required bash version in the future, - lack of bash-4.2 features affects a few eclasses already, resulting in work-around code, incl. multibuild, multiprocessing. Please don't empty the Whiteboard, it's an indicator that a member of the PMS team has looked at the bug. How much time is needed for "transition period"? Thanks for the info (In reply to comment #4) > How much time is needed for "transition period"? Thanks for the info Very good question. There's this council decision (http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt): | Upgrade path for old systems | ---------------------------- | Vote (unanimous): The ebuild tree must provide an upgrade path to a | stable system that hasn't been updated for one year. | | Action: leio will start a discussion on gentoo-dev on if and how to | support upgrading systems that are outdated more than a year. So the minimum is one year. IIRC, above mentioned "discussion on gentoo-dev" hasn't taken place yet. (In reply to comment #5) > (In reply to comment #4) > > How much time is needed for "transition period"? Thanks for the info > > Very good question. There's this council decision > (http://www.gentoo.org/proj/en/council/meeting-logs/20091109-summary.txt): > > | Upgrade path for old systems > | ---------------------------- > | Vote (unanimous): The ebuild tree must provide an upgrade path to a > | stable system that hasn't been updated for one year. > | > | Action: leio will start a discussion on gentoo-dev on if and how to > | support upgrading systems that are outdated more than a year. > > So the minimum is one year. IIRC, above mentioned "discussion on gentoo-dev" > hasn't taken place yet. I disagree. Introducing a new EAPI doesn't break the update path. Using it in system packages does. (In reply to comment #6) > I disagree. Introducing a new EAPI doesn't break the update path. Using it > in system packages does. A new EAPI doesn't break it. However, changing the bash version will break things, unless the package manager is capable of EAPI parsing and can therefore avoid sourcing such ebuilds. Should we go for version 4.3 instead? app-shells/bash-4.3_p39 is marked stable on all architectures. while that'd be nice, i'd be hesitant what with bash-4.3 being <2 years old, and bash-4.3 being in stable for <6 months conversely, bash-4.2 is 4.5 years old and has been in stable for 3.5 years Do you maybe recall which version changed behavior of ${PV/./~} to enable the tilde expansion inside it?
(In reply to Michał Górny from comment #10) bash-4.3 changed the behavior you're referring to just to be clear though, `echo ${PV/./~}` always expanded the tilde, but bash-4.3 changed it even when doing `echo "${PV/./~}"`. you have to do something like: echo "${PV/./'~'}" (In reply to SpanKY from comment #11) > bash-4.3 changed the behavior you're referring to bash-4.3 introduces a BASH_COMPAT variable. Package managers could assign BASH_COMPAT=4.2 in EAPI 6 to pin it down to the 4.2 behaviour. (Consequently, in EAPIs 0 to 5 it should be BASH_COMPAT=3.2, but I fear that would cause breakage. So maybe set it to 4.2 for these EAPIs too? Or alternatively, setting of BASH_COMPAT could be controlled by a feature like "strict-bash-version".) (In reply to SpanKY from comment #11) > (In reply to Michał Górny from comment #10) > > bash-4.3 changed the behavior you're referring to > > just to be clear though, `echo ${PV/./~}` always expanded the tilde, but > bash-4.3 changed it even when doing `echo "${PV/./~}"`. you have to do > something like: > echo "${PV/./'~'}" Then I'd say it would be better to require 4.3 to avoid the inconsistency on behavior. (In reply to Michał Górny from comment #13) > Then I'd say it would be better to require 4.3 to avoid the inconsistency on > behavior. The same will be true when 4.4 enters the tree. Whatever version we choose, there's always the chance that a newer version has incompatible changes. (In reply to Ulrich Müller from comment #14) > (In reply to Michał Górny from comment #13) > > Then I'd say it would be better to require 4.3 to avoid the inconsistency on > > behavior. > > The same will be true when 4.4 enters the tree. Whatever version we choose, > there's always the chance that a newer version has incompatible changes. Is this really a reason not to solve *known* problems? (In reply to Ulrich Müller from comment #12) while the variable is new to bash-4.3, bash-4.0 introduced a shopt to set the level: shopt -s compat42 this has the advantage of only impacting the immediate execution environment and not bleeding into children processes which themselves might be bash scripts. full disclosure: bash-4.2 has a bug where compat42 is wired to compat41 ;). while Gentoo has long carried a patch to fix it, upstream didn't release a patch, so using a non-Gentoo bash (e.g. on prefix systems) could be problematic. but while that'd be good with the ebuild itself, it would also mean any shell code the PM injects would also be constrained. today there's no such restriction. whether that's a big deal in practice, i'm not sure. we could always run a test in portage and see how it goes ... i think it'd be worth the effort. (In reply to Michał Górny from comment #15) i think you're overstating the impact of this particular behavior. i see ~12 packages in the tree that would be impacted, and half of them still don't quote the tilde, yet no one has complained. largely due to the fact that they're doing it to /_/~/ in PV and none have had a _ in the PV in a while. so we're back to bash-4.3 has barely been stable. if EAPI=6 is to come out any time soon (in the next 12 months), i don't think it makes sense to use bash-4.3 as the new base. (In reply to SpanKY from comment #16) > while the variable is new to bash-4.3, bash-4.0 introduced a shopt to set > the level: > shopt -s compat42 For some reason, they treat the shopt and the variable differently: $ echo $BASH_VERSION 4.3.42(1)-release $ shopt -s compat43 bash: shopt: compat43: invalid shell option name $ BASH_COMPAT=4.3 $ In other words, bash-4.3 doesn't have a compat43 shopt (and bash-4.2 doesn't have compat42). Makes it a bit awkward, because setting the option would need to be conditional on the version. Whereas the variable can be set to the current version without any problems. > this has the advantage of only impacting the immediate execution environment > and not bleeding into children processes which themselves might be bash > scripts. As long as BASH_COMPAT is not exported, this shouldn't be a problem. (?) (In reply to Ulrich Müller from comment #18) that does seem like bad form. let me bring it up on the bash lists. my vague recollection of portage saving/restoring of the env is that it doesn't really treat exported/non-exported differently. anything that's in the env is exported. that doesn't mean portage can't take care of scrubbing this var from the env and manually resetting it every time, so it might be feasible. i'd still prefer the shopt route myself as it's more robust, even if the interface is bad atm :). looks like they intend on dropping the shopt levels and only supporting BASH_COMPAT. so we'll need to do something like:
local maj=4 min=2
if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] ||
[[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min ]]) ; then
die ">=bash-${maj}.${min} is required"
fi
BASH_COMPAT="${maj}.${min}"
and then update portage to filter that out so we make sure it doesn't get exported to other shell scripts.
Upstream bash discussion: https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00103.html In EAPI 6: https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=d0471958f3a9b1396cfbe8b54dd53747d32ffaba Bash compatibility level: https://gitweb.gentoo.org/proj/pms.git/commit/?h=eapi-7&id=01346659dfaf4057107dacc38bbeb7e7b0fc5e4f (In reply to Ulrich Müller from comment #22) Sorry, wrong branch. Correct URIs for the commits are: https://gitweb.gentoo.org/proj/pms.git/commit/?id=d0471958f3a9b1396cfbe8b54dd53747d32ffaba https://gitweb.gentoo.org/proj/pms.git/commit/?id=01346659dfaf4057107dacc38bbeb7e7b0fc5e4f (In reply to SpanKY from comment #20) > looks like they intend on dropping the shopt levels and only supporting > BASH_COMPAT. so we'll need to do something like: > local maj=4 min=2 > if ([[ ${BASH_VERSINFO[0]} -lt ${maj} ]] || > [[ ${BASH_VERSINFO[0]} -eq ${maj} && ${BASH_VERSINFO[1]} -lt ${min ]]) > ; then > die ">=bash-${maj}.${min} is required" > fi > BASH_COMPAT="${maj}.${min}" > > and then update portage to filter that out so we make sure it doesn't get > exported to other shell scripts. @vapier: Are you going to provide a patch for Portage? (In reply to Ulrich Müller from comment #24) https://archives.gentoo.org/gentoo-portage-dev/message/6822a19097d69cf14338d48be520afe7 |
