Re: [Bash-completion-devel] [RFC] Completions location
On Tuesday 22 September 2009, Elan Ruusamäe wrote: On Monday 21 September 2009 22:36:18 Guillaume Rousse wrote: Ville Skyttä a écrit : http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/devel/bash- completion.spec?revision=1.42view=markup Interesting. Maybe a bit of lua scripting could help also here. same (similar) approach already in pld linux package, from which the thread started: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/bash-completion/bash-c ompletion.spec?rev=1.153;content-type=text/x-cvsweb-markup Ah yes, I had forgotten about that approach - I used practically that one some 4 years ago in Fedora but later reverted to the slightly clumsier approach currently employed in order to make the package buildable with older rpm versions in RHEL with which I couldn't get %bashcomp_trigger macro definition to work. Glad to see others found use for it, and I should probably see if I could revert back to it these days again. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [RFC] Completions location
David Paleino a écrit : On Sun, 20 Sep 2009 22:06:16 +0200, Guillaume Rousse wrote: You're mixing two issues here. The first one is where is the code to be developped and maintained: either splitted in various upstream projects, or centralized in bash-completion project. The second one is where the the code is to be packaged in various linux distributions, either splitted in various packages, or centralized in bash-completion package. The two issues are only loosely related. Not really, IMHO :) (see next paragraph) For instance, in Mandriva, various completions were shipped in the package they were related to, even if developped elsewhere. Of course, mapping packages to software projects is usually easier on the long term, that's why I reverted to the centralised distribution in bash-completion package. Exactly: there's a *big* maintainance overhead for distributions, if we keep completions in our project and have to ship them on a per-package basis downstream. For the last issue, which is to distribute in a single package, and activate only when needed, I initially attempted to use triggers too. However, we now have 175 various completions in contrib directories, meaning 175 * 2 triggers (installation/uninstallation) to maintain, keeping track of the various mismatch between package names and completion file name. All in all, that's just impossible. Is it necessary to do that manually? I mean, when I thought at completions using triggers, I was imagening the following scenario: a) we have a package foo downstream, for which we created a completion foo in our project; b) the package maintainer of foo does something to activate foo completion. In the simplest case, symlinks the completion from /usr/share/bash-completion/contrib/foo to /etc/bash_completion.d/foo; c) this would've been done automatically, i.e. by *default* if there's a matching completion in /usr/share/bash-completion/contrib/, symlink it to the proper location. Regarding point c), I was thinking at packages matching the completion name. But there could also be completions whose name doesn't match with the downstream package name. In this case, I was thinking that's maintainer's duty (if the names don't match, otherwise it's automatically done) to specify in some field (in debian/control, or in RPM's .spec) the completions to activate if available. This way, each time we create a new completion, we just need to file a bug to the respective downstream packages, something like hey, beware that in next bash-completion release, you will have this additional completion. Please handle it appropriately. I don't see much difference with adding a post-installation procedure in another package, and adding a trigger for it in bash-completion package. That's still 178 modifications to do (and I usually prefer to commit them myself, rather than open 178 tickets, and waiting for other maintainers to do it). And the 'symlink on install' procedure from another package will only work if bash-completion is already present at installation time (and I had strong opposition to make bash-completion a mandatory dependency of minimal system in the past). If you install it later, it won't work. Again, only package trigger offer a 100% working solution. The intent of the script I recently commited in the project (install-completions), is to leverage this problem, by automatically selecting which completions from installation directory (for instance, /usr/share/bash-completion) are relevant, and symlinking them to the place where they are actually sourced (/etc/bash-completion.d). This way, I just have to call 'install-completions /usr/share/bash-completion /etc/bash-completion.d' during package post-installation procedure, and 'symlinks -d /etc/bash-completion.d' during post-uninstallation procedure. Of course, this does not automatically add new completions for packages installed later, but users are also able to rerun the script themselves. That's fine when the user installs bash-completion -- and when upgrades it, but we'd totally lose completions for installed programs during the two releases (be them up- or downstream). And, in my opinion, giving the user a cli command to activate them, shouldn't be the only way to go -- at most that can be an helper script, when triggers aren't supported in the distribution. IMHO this should be transparent to the user: 1) user installs bash-completion, and it makes symlinks for installed packages 2) each package installation triggers the completion activation (with the mechanisms I explained above) 2 seems to be out of reach for me currently, and 1 is only a cheap workaround. Anyway, just because it can't be fully automated doesn't mean users can't configure it themselves, if properly documented. -- BOFH excuse #143: had to use hammer to free stuck disk drive heads. ___
Re: [Bash-completion-devel] [RFC] Completions location
Ville Skyttä a écrit : For the last issue, which is to distribute in a single package, and activate only when needed, I initially attempted to use triggers too. However, we now have 175 various completions in contrib directories, meaning 175 * 2 triggers (installation/uninstallation) to maintain, keeping track of the various mismatch between package names and completion file name. All in all, that's just impossible. This is surely a bit (yep, a bit, not a lot) of work, but why would it be impossible? I haven't packaged post 1.0 bash-completion for Fedora but I do for now intend to continue with the trigger approach. With a few helper macros I think it's quite manageable, see http://cvs.fedoraproject.org/viewvc/rpms/bash-completion/devel/bash- completion.spec?revision=1.42view=markup Interesting. Maybe a bit of lua scripting could help also here. -- BOFH excuse #319: Your computer hasn't been returning all the bits it gets from the Internet. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [RFC] Completions location
David Paleino a écrit : Hello, I remember we decided to push all completions to respective upstreams, but didn't decide anything more than that, at the time. -- or it could've been a joke of my mind :) On IRC the discussion was raised by the maintainer of the PLD package. He has a few points, which I believe we already discussed about, with some new features: 1) upstreams won't possibly handle completions like we can -- be it syntactically, stylistically, functionally; 2) we would lose maintainance of the completions. Or, if we want to keep it, it would be a nightmare: we would need a $vcs write access for the completion for each software package. A mess. 3) bash-completion will rapidly decrease in performance, because of probably poorly written code. The proposal made by Elan is: let's keep all completions in our repository (and released package), and use package managers triggers to install them. I know .deb has it (but never done that, should do a bit of research), and Elan said .rpm has that too. What about emerge? Other distros? Obviously, before using these triggers, we should change directory layout. You're mixing two issues here. The first one is where is the code to be developped and maintained: either splitted in various upstream projects, or centralized in bash-completion project. The second one is where the the code is to be packaged in various linux distributions, either splitted in various packages, or centralized in bash-completion package. The two issues are only loosely related. For instance, in Mandriva, various completions were shipped in the package they were related to, even if developped elsewhere. Of course, mapping packages to software projects is usually easier on the long term, that's why I reverted to the centralised distribution in bash-completion package. For the last issue, which is to distribute in a single package, and activate only when needed, I initially attempted to use triggers too. However, we now have 175 various completions in contrib directories, meaning 175 * 2 triggers (installation/uninstallation) to maintain, keeping track of the various mismatch between package names and completion file name. All in all, that's just impossible. The intent of the script I recently commited in the project (install-completions), is to leverage this problem, by automatically selecting which completions from installation directory (for instance, /usr/share/bash-completion) are relevant, and symlinking them to the place where they are actually sourced (/etc/bash-completion.d). This way, I just have to call 'install-completions /usr/share/bash-completion /etc/bash-completion.d' during package post-installation procedure, and 'symlinks -d /etc/bash-completion.d' during post-uninstallation procedure. Of course, this does not automatically add new completions for packages installed later, but users are also able to rerun the script themselves. -- BOFH excuse #304: routing problems on the neural net ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
