Created attachment 350726 [details] bash-completion-2.1-r1.ebuild Let's drop the wrapper script and change installation paths to upstream defaults. :) Some facts. From the README [1]: "There are two alternatives: the recommended one is 'completionsdir' (get it with "pkg-config --variable=completionsdir bash-completion") from which completions are loaded on demand based on invoked commands' names, so be sure to name your completion file accordingly, and to include for example symbolic links in case the file provides completions for more than one command. The other one which is present for backwards compatibility reasons is 'compatdir' (get it with "pkg-config --variable=compatdir bash-completion") from which files are loaded when bash_completion is loaded." By default completionsdir="/usr/share/bash-completion/completions" and compatdir="/etc/bash_completion.d". With current bash-completion-2.1 ebuild from the portage tree dynamic loading of completions does not work because they are installed in "/usr/share/bash-completion". Some completions may not support loading on demand. Currently I'm aware of only one: gentoo-bashcomp. Name of completions provided by gentoo-bashcomp does not match commands' names. They could be enabled globally using bashcomp-eselect, so that symlinks are created in "/etc/bash_completion.d/" (compatdir). The same also applies to completions which support loading on demand, but installed in "/usr/share/bash-completion". Loading competions from "~/.bash_completion.d" is not supported. TODO/Qeustions: - bash-completion-2.1 ebuild: add postinst messages - gentoo-bashcomp: file a bug requesting to support loading completions on demand - What is the migration strategy? What to do with ebuilds installing completions in "/usr/share/bash-completion"? What to do with bash-completion-r1.eclass? etc... [1] http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=blob;f=README
I did some work on gentoo-bashcomp last year before getting sidetracked. I'll try to get back to it and work on a migration plan. I think we should eventually get rid of the eselect module and load everything dynamically. The bulk of the work can be done in the eclass, but I'm thinking it's going to be tricky to handle both versions at the same time. It might be better to add an -r2 eclass and port ebuilds over.
Created attachment 350854 [details, diff] bash-completion-r1.eclass.patch New functions get_bashcompdir and less used get_bashhelpersdir, - Use pkg-config (like systemd.eclass, udev.eclass, etc.) but have fallbacks for everything to cause minimal blockers. - Provide migration path to upstream bash-completion system. No bash-completion-r2.eclass required. Notes, As per Comment #1, gentoo-bashcomp is blocked from the new ebuild for now. Example usage, --- sys-fs/udisks/udisks-2.1.0.ebuild +++ sys-fs/udisks/udisks-2.1.0.ebuild @@ -80,7 +80,8 @@ keepdir /var/lib/udisks2 #383091 rm -rf "${ED}"/usr/share/bash-completion - dobashcomp data/completions/udisksctl + insinto "$(get_bashcompdir)" + doins data/completions/udisksctl local htmldir=udisks2 if [[ -d ${ED}/usr/share/doc/${PF}/html/${htmldir} ]]; then Will attach the ebuild patch too.
Created attachment 350856 [details, diff] From current 2.1 to 2.1-r1 build patch
(In reply to Samuli Suominen from comment #2) > New functions get_bashcompdir and less used get_bashhelpersdir, See bug 469858 > As per Comment #1, gentoo-bashcomp is blocked from the new ebuild for now. gentoo-bashcomp works fine if completions enabled globally (eselect bashcomp enable --global {eselect,gentoo,repoman}). Also there is a quick temporary fix for gentoo-bashcomp: install completions in /etc/bash_completion.d/. -insinto /usr/share/bash-completion +insinto /etc/bash_completion.d (In reply to Samuli Suominen from comment #3) > +RDEPEND="|| ( >=app-shells/bash-3.2 app-shells/zsh ) From the README: "Use the full power of bash >= 4.1. We no longer support earlier bash versions, so you may as well use all the features of that version of bash to optimise your code. However, be careful when using features added since bash 4.1, since not everyone will be able to use them." > - elog "If you use non-login shells you still need to source" > - elog "/etc/profile.d/bash-completion.sh in your ~/.bashrc." Please add something like this into pkg_postinst(): elog "If you use non-login shells you still need to source" elog "/usr/share/bash-completion/bash_completion" elog "in your ~/.bashrc. For example:" elog "[[ \$PS1 && -f /usr/share/bash-completion/bash_completion ]] && \\" elog " . /usr/share/bash-completion/bash_completion"
(In reply to Samuli Suominen from comment #2) > Created attachment 350854 [details, diff] [details, diff] > bash-completion-r1.eclass.patch > > New functions get_bashcompdir and less used get_bashhelpersdir, > > - Use pkg-config (like systemd.eclass, udev.eclass, etc.) but have fallbacks > for everything to cause minimal blockers. > > - Provide migration path to upstream bash-completion system. No > bash-completion-r2.eclass required. That's not a bad option, but I still like the simplicity of just being able to call dobashcomp. It's idiot-proof and if we ever need to hook in other features/fixes later we can do it once in the eclass rather than modify a ton of ebuilds. It also makes migrating ebuilds nothing but a simple tweak of the inherit line.
(In reply to Ryan Hill from comment #5) > (In reply to Samuli Suominen from comment #2) > > Created attachment 350854 [details, diff] [details, diff] [details, diff] > > bash-completion-r1.eclass.patch > > > > New functions get_bashcompdir and less used get_bashhelpersdir, > > > > - Use pkg-config (like systemd.eclass, udev.eclass, etc.) but have fallbacks > > for everything to cause minimal blockers. > > > > - Provide migration path to upstream bash-completion system. No > > bash-completion-r2.eclass required. > > That's not a bad option, but I still like the simplicity of just being able > to call dobashcomp. It's idiot-proof and if we ever need to hook in other > features/fixes later we can do it once in the eclass rather than modify a > ton of ebuilds. It also makes migrating ebuilds nothing but a simple tweak > of the inherit line. Sure, the patch to the eclass just makes the dobashcomp use pkg-config to determine completionsdir You can keep on using it
I completely missed that part of the patch. Looks good to me.
Can we start preparing ebuilds which hardcodes /usr/share/bash-completion path for migration? get_bashcompdir() function is already supported by eclass [1]. If yes, then we need a tracker. [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/bash-completion-r1.eclass?r1=1.3&r2=1.4
2.1-r1 in tree and eclass updated, closing
*** Bug 477024 has been marked as a duplicate of this bug. ***
Looks like this was dropped finally
(In reply to Pacho Ramos from comment #11) > Looks like this was dropped finally I removed 2.1-r1 because some loud people complained they couldn't no longer prevent specific bash-completions from being loaded As in, 2.1-r1 no longer used eselect-bashcomp I personally used INSTALL_MASK to drop 2 problematic bash-completion files, and was fine with that solution, but this wasn't enough for everyone So, a new version of eselect-bashcomp "needs" to be created that works in a way that you can disable specific ones, like, move them out of /usr/share/bash-completion/completions/ to some temporary directory like /usr/share/bash-completion/completions.eselect/ I'm no longer working on this, I'm just clarifying why 2.1-r1 was removed, this is why, the lack of newly written eselect-bashcomp module that works reverse from the current one
In case anyone wants to play with this, p.masked >=bash-completion-2.1-r90 is the (second attempt) initial ebuild.
*** Bug 476992 has been marked as a duplicate of this bug. ***
2.1-r91 is now in ~arch. Enjoy the new issues!
