This is a beta release (pre-2.0) and a very good opportunity to remove Gentoo compatibility wrappers (for loading) [in the same way upstream dropped support for bash < 4.1] - the test-suite should be supported (but it stills fails for the moment). - sys-apps/miscfiles dependency has been dropped : it's only needed for dict(1) completion. So a "bash-completion" useflag for the ebuild(s) providing dict(1) (like app-text/dictd) is more suited for this - support for zsh has been dropped from the ebuild (until someone is willing to test it) - some typos in postinst() have been fixed Reproducible: Always
Created attachment 296147 [details] ebuild for bash-completion-1.90
Rereading the post-installation message, we may even replace > elog ".bashrc by running:" by > elog "~/.bash_completion.d directory by running:"
Please provide a patch when modifying ebuilds for existing packages.
Hi there. * Why do you completely drop the wrapper? Specifically, what is your migration strategy with regards to .pre, base, .post?
AFAICT upstream 1.9x takes into account : * dynamic completion loading (so most of the current completion symlinks may be dropped) * user disabling unconditionnal system completions (shopt in ~/.bash_completion) [1] and defining some configuration (COMP_* variables) * user enabling unconditionnal custom completion using `export BASH_COMPLETION_COMPAT_DIR=$HOME/.bash_completion.d` (but I don't know if there are other recommanded solutions) * system-wide unconditionnal completion loading using BASH_COMPLETION_COMPAT_DIR * user doing any other random stuff : ~/.bash_completion So the only directory for which some gentoo tweaks may be needed is ~/.bash_completion.d/*, but it would 1) only avoid a trivial configuration addition, useless for most users and 2) not be really important since completions are now dynamically loaded. I don't really thought about a migration strategy but most of it would be related to the eselect bashcomp module because the only sad thing I can think about with the new release is to have a bunch of completion being forgotten /etc/bash_completion.d and ~/.bash_completion.d thus cancelling the main benefit of dynamic completion loading. [1] or rather ${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion
*** Bug 423419 has been marked as a duplicate of this bug. ***
1. bash-completion-2.1 was released 2. We definetly need >=bash-completion-2.0. Some modern software tries to use pkg-config to get a directory to store bash completions. If no bash-completion.pc is found (this is true for bash-completion-1.3), then they fall back to /usr/share/bash-completion/completions, and such completions can't be selected via "eselect bashcomp". # qfile -qC /usr/share/bash-completion/completions sys-apps/systemd sys-kernel/dracut also see: bug 465094 bug 465100 This is from systemd's configure script: # Check whether --with-bashcompletiondir was given. if test "${with_bashcompletiondir+set}" = set; then : withval=$with_bashcompletiondir; else if $($PKG_CONFIG --exists bash-completion); then : with_bashcompletiondir=$($PKG_CONFIG --variable=completionsdir bash-completion) else with_bashcompletiondir=${datadir}/bash-completion/completions fi fi
Sorry, bash-completion.pc was already backported. *bash-completion-1.3-r1 (01 Nov 2012) 01 Nov 2012; Samuli Suominen <ssuominen@gentoo.org> +bash-completion-1.3-r1.ebuild, +files/bash-completion.pc: Backport modified bash-completion.pc pkg-config file from upstream 2.0 release.
Bumped to 2.1. I am not seeing any problems here except with stale files left in some users' ~/.bash_completion.d/ . Maybe leave this open for a bit to catch problems?
(In reply to Jeroen Roovers from comment #9) > Bumped to 2.1. I am not seeing any problems here except with stale files > left in some users' ~/.bash_completion.d/ . Maybe leave this open for a bit > to catch problems? Attempting to upgrade on ~amd64 just now: * Detected file collision(s): * * /usr/share/bash-completion/ionice * /usr/share/bash-completion/hwclock * /usr/share/bash-completion/renice * /usr/share/bash-completion/eject * /usr/share/bash-completion/look * /usr/share/bash-completion/cal * /usr/share/bash-completion/hexdump * /usr/share/bash-completion/dmesg * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * sys-apps/util-linux-2.23:0::gentoo * /usr/share/bash-completion/cal * /usr/share/bash-completion/dmesg * /usr/share/bash-completion/eject * /usr/share/bash-completion/hexdump * /usr/share/bash-completion/hwclock * /usr/share/bash-completion/ionice * /usr/share/bash-completion/look * /usr/share/bash-completion/renice If additional information is necessary, please let me know and I'd be happy to provide it.
(In reply to Greg Kubaryk from comment #10) > (In reply to Jeroen Roovers from comment #9) > > Bumped to 2.1. I am not seeing any problems here except with stale files > > left in some users' ~/.bash_completion.d/ . Maybe leave this open for a bit > > to catch problems? > > Attempting to upgrade on ~amd64 just now: > > * Detected file collision(s): > * > * /usr/share/bash-completion/ionice > * /usr/share/bash-completion/hwclock > * /usr/share/bash-completion/renice > * /usr/share/bash-completion/eject > * /usr/share/bash-completion/look > * /usr/share/bash-completion/cal > * /usr/share/bash-completion/hexdump > * /usr/share/bash-completion/dmesg > * > * Searching all installed packages for file collisions... > * > * Press Ctrl-C to Stop > * > * sys-apps/util-linux-2.23:0::gentoo > * /usr/share/bash-completion/cal > * /usr/share/bash-completion/dmesg > * /usr/share/bash-completion/eject > * /usr/share/bash-completion/hexdump > * /usr/share/bash-completion/hwclock > * /usr/share/bash-completion/ionice > * /usr/share/bash-completion/look > * /usr/share/bash-completion/renice > > If additional information is necessary, please let me know and I'd be happy > to provide it. That should have been fixed with bug #468544 which explicitly removes the rtcwake completion in the bash-completion ebuild but leaves other files in place. It's fixed now, though.
(In reply to Jeroen Roovers from comment #11) > It's fixed now, though. Sure is. Thanks. Looks like #472250 may be duplicate. I guess we messed up by conflating two issues in one bug, but hey, it's fixed now.
Uh, how are you planning on addressing the whole migration strategy and wrapper setup? That's what was holding this bug back.
(In reply to Ryan Hill from comment #13) > Uh, how are you planning on addressing the whole migration strategy and > wrapper setup? That's what was holding this bug back. That's what comment #3 is about? What is holding us back, then?
Comment #4 I meant.
If there are outstanding issues, they should be reported as separate bugs that block this one.
Two questions. 1. Why we need the wrapper and eselect module with bash-completion-2? I always thought that they need to solve performance problems (in bash-completion-1 all modules are loaded at once). Loading modules on demand is supported since bash-completion 1.90 (2.0 preview). 2. Why we still use non-standard directory for completions? Upstream and all modern distributions are using "/usr/share/bash-completion/completions". Most packages installs completions in this directory by default. Several ebuilds currently change this path to "/usr/share/bash-completion" using sed, and many ebuilds simply do something like this at install phase: rm -rf "${ED}"/usr/share/bash-completion dobashcomp path/to/bashcomp Is there a plan to address this issues?
We shouldn't need the eselect module now IIUC. I haven't looked into how exactly dynamic loading works. I keep meaning to but, you know... Alexander/Raphaël, is anything broken by this version bump? If not then I say we leave it as is and file a couple enhancement bugs to deprecate the eselect module and migrate the install path.
Created attachment 350866 [details] See http://bugs.gentoo.org/472938 for files Files at bug 472938
*** Bug 476270 has been marked as a duplicate of this bug. ***
What is the point to close #476270 as duplicate instead of making dependent on this one?
(In reply to Evgeny Bobkin from comment #21) > What is the point to close #476270 as duplicate instead of making dependent > on this one? because this one solves that one directly 2.1-r1 in tree, closing
