[Bash-completion-devel] [RFC] Completions location

[Guillaume Rousse]

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.