Benjamin,
Answers below:
On 17. 11. 15 21:20, Benjamin Drung wrote:
Hi Nicholas,
I have a few questions about that applied patch:
1) Why do you copy all bash completions to BC_BUILD_DIR? I see no
reason for that additional step.
The problem is that the scripts in the
/usr/share/bash-completion/completions must share the same name as the
command they are helping. So obviously they can no longer be in the same
build directory ( $top_srcdir/scripts ) as the actual scripts as those
will by necessity have the same name.
2) Why do you 'pkgnames' into the bash completions directory? There is
no such script. Wouldn't it be better to use on of the existing names
(like bts) and point all symlinks to that?
This script (which I did not write) does a very simple action of just
offering up package names. This suffices (or at least is purported to
suffice for a large number of commands.) I left it as it was for the
following reasons:
1.) The name describes what it does - deliver package names.
2.) It has historically been called devscripts.pkgnames and my solution
offered continuity. Or in other words I saw no reason to change it.
3.) I am happy to try and work through all the commands and give them
optimal bash completions. Eventually this one may therefore diusappear
all together.
4.) I documented in the change log that this one is an exception for
generic bash completion.
3) Why do you create the symlinks via debian/links instead of the
Makefile where you do all the other magic?
This is actually a fair point, although I see no alternative. James
stated AFAIR that he wanted the devscripts to pick up the location of
the bash completion directory from the bash-completion package as we do
in the scripts/Makefile. Putting these links in debian/links does not
currently support this.
I did experiment with trying to create the symlinks inside
$BC_BUILD_DIR. But then all that happens is that you do not get symlinks
at all.
I guess you could have some symbolic links in the install step of
scripts/Makefile. But I am not sure that is any better. We have a
separate dh_link step for a reason.
I think a better approach would be if the dh-exec package could be
extended to support debian/links. Then you could put variables in
debian/links.
