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.
_______________________________________________
Bash-completion-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
