Created attachment 448960 [details] A proof of concept ebuild with simple modifications. To make testing easier with newer versions of bash, instead of hard-coded-ly enabling use of installed readline to release versions of bash, and disabling it in pre-release versions, it would be better if we would allow the user to choose which readline library bash would link to, by the 'system-readline' flag. Since we disable keywords in pre-release versions, we wouldn't have to worry that a user would accidentally install a pre-release version of readline. Attached is a simple P.O.C. ebuild for it. For the flag's info in metadata.xml, we can have: '<flag name="system-readline">Use the system-wide sys-libs/readline</flag>', which is borrowed from www-client/firefox. This was discussed in this thread: https://archives.gentoo.org/gentoo-dev/message/784efe2aebde856e4f34f4c0d9ca9d48. (Alt.: https://marc.info/?l=gentoo-dev&m=147538613209208&w=2)
Created attachment 448964 [details] Another version that is more configurable This version allows disabling the feature completely in versions of bash that doesn't have a paired readline library package yet, by unsetting the READLINE_VER variable. I also added my fix for tinfo because I needed it.
By the way, the line [[ ${IS_A_RELEASE} == true ]] && KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" can be changed to two lines if it looks unnatural: KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~amd64-fbsd ~sparc-fbsd ~x86-fbsd" [[ ${IS_A_RELEASE} == false ]] && KEYWORDS=
How is this different from the functionality of the readline use flag bash already has? Thanks, William
(In reply to William Hubbs from comment #3) > How is this different from the functionality of the readline use flag > bash already has? The 'readline' flag only decides if bash would compile with readline support or not, not decide which readline to compile to. To be more precise, the 'readline' flag affects the '--with-readline' option; the 'system-readline' flag affects the '--with-installed-readline' option. Adding the new flag would allow the user to install newer versions of bash without needing to install a new readline right away and rebuild all the packages that depend on it. This would allow them to try the new versions of bash or other versions not compatible with the currently installed readline with less trouble, and less risk. As you can see, the current ebuild implementations make bash compile against the system-wide readline if the version is a release, and not if it's a pre-release. We just allow the user to have more control over it.
(In reply to konsolebox from comment #4) > 'readline' flag affects the '--with-readline' option Sorry it's actually '--enable-readline'.
I think I would like a bundled-readline use flag instead. This would be turned off by default, and you would activate it if you want to build bash with the bundled readline implementation.
(In reply to William Hubbs from comment #6) > I think I would like a bundled-readline use flag instead. > This would be turned off by default, and you would activate it if you > want to build bash with the bundled readline implementation. That looks ok too to me.
So any chance this feature would be included?
sorry but i don't see value in this
(In reply to SpanKY from comment #9) > sorry but i don't see value in this Like I said, this would be helpful for testing newer versions of Bash (which includes new versions and alpha/beta/rc versions) since you wouldn't have to rebuild readline. Do you not agree with that? Anyway, thanks for making it clear that this won't be added. It could have been helpful to other users who develop bash applications needing to test their scripts to newer versions of bash.
(In reply to konsolebox from comment #10) bash alpha/beta/rc versions are pretty uncommon, and when they're in the tree, they're masked (no KEYWORDS). the number of people who are installing/testing these ahead of time is pretty low. which means the number of people using USE=system-readline would be even lower. even the final release (e.g. 4.4) wouldn't go into ~arch straight away. by the time things hit ~arch, bash has seen enough usage to justify it.
(In reply to SpanKY from comment #11) > (In reply to konsolebox from comment #10) > > bash alpha/beta/rc versions are pretty uncommon, and when they're in the > tree, they're masked (no KEYWORDS). the number of people who are > installing/testing these ahead of time is pretty low. which means the > number of people using USE=system-readline would be even lower. even the > final release (e.g. 4.4) wouldn't go into ~arch straight away. > > by the time things hit ~arch, bash has seen enough usage to justify it. I guess you're choosing minimalism over control and flexibility just because only few people would be using it. And I thought you said there's "no" value. It's even not only about testing. Sometimes people would want to revert back to old versions without needing to rebuild readline and the whole tree that depends on it. Even right now I'm noticing significant speed regressions in 4.4. > even the final release (e.g. 4.4) wouldn't go into ~arch straight away. That's surprising. I was able to install 4.4 during the time the looking-for-testers email was sent in the list, without needing to add an ** entry in package.keywords. Or does that imply the testing of the developers before it gains that keyword? How about the testing phase of the users?
(In reply to konsolebox from comment #12) how is downgrading relevant to your argument ? if you read the ebuild: readline? ( >=sys-libs/readline-${READLINE_VER}:0= ) older versions of bash have no problem building against newer readlines. in fact, all the way back to bash-2.05b builds just fine against readline-7. so there is no requirement to downgrade your readline and thus no need to rebuild its deps. the crux of that argument though really applies to every package out there that forces a newer library that happens to have a diff SONAME and trigger rebuilds. we don't special case any of those, nor do i think we should make an exception here. i don't see value in supporting a scenario that one or two people would actually utilize and "need" to do so. the bash ebuild is already complicated w/out tacking on more esoteric functionality.
(In reply to SpanKY from comment #13) > (In reply to konsolebox from comment #12) > > how is downgrading relevant to your argument ? if you read the ebuild: > readline? ( >=sys-libs/readline-${READLINE_VER}:0= ) > > older versions of bash have no problem building against newer readlines. in > fact, all the way back to bash-2.05b builds just fine against readline-7. > so there is no requirement to downgrade your readline and thus no need to > rebuild its deps. > > the crux of that argument though really applies to every package out there > that forces a newer library that happens to have a diff SONAME and trigger > rebuilds. we don't special case any of those, nor do i think we should make > an exception here. i don't see value in supporting a scenario that one or > two people would actually utilize and "need" to do so. Ok I said enough. I guess in the end it's all about not adding the function because only a few would use it, unless there are other personal reasons. The ebuild would solely remain configurable to its maintainers only. > the bash ebuild is > already complicated w/out tacking on more esoteric functionality. The code indeed can still make use of some simplifications and better bash-scripting practices (most probably with the patches() function), but I don't see it that complicated as a whole, and so is this new function. My patch has even made the code a bit more consistent and understandable.
