Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 431340 - [Future EAPI] Allow bash-4.2 features
Summary: [Future EAPI] Allow bash-4.2 features
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All All
: Normal enhancement (vote)
Assignee: PMS/EAPI
URL:
Whiteboard: in-eapi-6
Keywords:
Depends on:
Blocks: future-eapi 414811 463822
  Show dependency tree
 
Reported: 2012-08-14 07:10 UTC by Arfrever Frehtes Taifersar Arahesis
Modified: 2017-11-05 18:34 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arfrever Frehtes Taifersar Arahesis 2012-08-14 07:10:40 UTC
bash-4.2 features should be allowed in future EAPIs (in global scope and local scope).
Comment 1 Ulrich Müller gentoo-dev 2012-08-14 07:33:20 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.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-14 09:04:37 UTC
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.
Comment 3 Ulrich Müller gentoo-dev 2013-03-14 11:45:25 UTC
Please don't empty the Whiteboard, it's an indicator that a member of the PMS team has looked at the bug.
Comment 4 Pacho Ramos gentoo-dev 2013-03-14 19:29:04 UTC
How much time is needed for "transition period"? Thanks for the info
Comment 5 Ulrich Müller gentoo-dev 2013-03-14 19:49:07 UTC
(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.
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-03-14 20:42:37 UTC
(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.
Comment 7 Ulrich Müller gentoo-dev 2013-03-14 22:17:27 UTC
(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.
Comment 8 Ulrich Müller gentoo-dev 2015-10-14 21:37:07 UTC
Should we go for version 4.3 instead? app-shells/bash-4.3_p39 is marked stable on all architectures.
Comment 9 SpanKY gentoo-dev 2015-10-15 03:34:55 UTC
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
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-10-15 04:05:11 UTC
Do you maybe recall which version changed behavior of ${PV/./~} to enable the tilde expansion inside it?
Comment 11 SpanKY gentoo-dev 2015-10-15 04:17:34 UTC
(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/./'~'}"
Comment 12 Ulrich Müller gentoo-dev 2015-10-15 06:20:47 UTC
(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".)
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-10-15 10:46:52 UTC
(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.
Comment 14 Ulrich Müller gentoo-dev 2015-10-15 11:19:06 UTC
(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.
Comment 15 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-10-15 11:55:09 UTC
(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?
Comment 16 SpanKY gentoo-dev 2015-10-15 14:55:47 UTC
(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.
Comment 17 SpanKY gentoo-dev 2015-10-15 14:56:31 UTC
(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.
Comment 18 Ulrich Müller gentoo-dev 2015-10-15 16:43:28 UTC
(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. (?)
Comment 19 SpanKY gentoo-dev 2015-10-15 17:17:15 UTC
(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 :).
Comment 20 SpanKY gentoo-dev 2015-10-15 19:30:20 UTC
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.
Comment 21 Ulrich Müller gentoo-dev 2015-10-16 09:01:27 UTC
Upstream bash discussion:
https://lists.gnu.org/archive/html/bug-bash/2015-10/msg00103.html
Comment 24 Ulrich Müller gentoo-dev 2015-11-11 01:59:33 UTC
(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?