Re: Bug#144337: kernel-package: Right location for bash completion script

[Rafael Laboissiere <laboissiere@mpipf-muenchen.mpg.de>]

In a private discussion with Manoj Srivastava and Matthias Klose (triggered
by Bug#144337), an important issue has been raised about where Debian
packages should put add-on bash completions scripts.

The Debian version of the /etc/bash_completion script has been modified by
Matthias Klose (the maintainer of the bash package) such that it sources
files in the following directories (in this order):

    1) /usr/share/bash_completion
    2) /etc/bash_completions.d/

and then it sources the file

    3) ~/.bash_completion

IMO, it makes sense that completion scripts provided by other Debian
packages (like Manoj's make-kpkg) should go into /usr/share/bash_completion.
If the user wants to override the definitions in make-kpkg, she puts the
necessary code in ~/.bash_completion.  If the system administrator wants to
override the code in a site-wide manner, she just adds a file in
/etc/bash_completions.d/.

However, Manoj strongly disagrees with my position above.  Here is a quote
of his arguments:

* Manoj Srivastava <srivasta@debian.org> [2002-04-25 18:03]:

> It can't work if I want to just add or comment a line or a part of a file.
> If a file defines 32 completions, and I want to comment 12, and modify 3, I
> should be able to do so. And not have things change if the maintainer
> decides to add 5 more completions, 4 of which I do not want. I should not
> have to go scanning files in /usr/share for configuration info I should now
> have to negate.
> 
> Making users scan files in arbitary locations and write code to prevent
> modification of their configuration is bletcherous.
> 
> I have discussed this on IRC with Wichert Akkerman, and Anthony Towns,
> amongst others, and we are all of the opinion completion files are
> configuration files. As soon as woody is released, this shall be filed as a
> serious bug (after talking with the release manager, I am holding off until
> after the release).
> 
> 	Please also mention the following points for my position:
> 
> 	a) this changes the internal behaviour and user interface of
> 	   bash, this is a change of builtin behaviour.
>         b) It is a file read in during the configuration file parsing
>            phase, is not data, really, but configuration
>  These two meet the requirements of configuration file in policy 11.7
>         c) It is a file that users may reasonably wish to modify, and
>            I can demonstrate significant advantages of one line
>            modifications for completion
>         d) Users should not have to write code or else have the
>            configuration of their shell change mysteriously from out
>            under them
> 
> Unlike the spurious ``any program changes the behaviour of bash'', which is
> patently untrue, since bash does not change, it merely executes programs in
> the path; there has been no real objection to any of this.

It has also been considered to reopen Bug#144337 and assign it to bash:

>  Perhaps the bug should be reopened and assigned to bash?
> 
> "Rafael" == Rafael Laboissiere <laboissiere@mpipf-muenchen.mpg.de> writes:
>
>  Rafael> I do not think that this bug should be assigned to bash.
>  Rafael> Actually, it is not a "bug", but a kind of "policy" for the
>  Rafael> Debian bash completion add-ons.
> 
> 	It is a bug. 11.7 of policy is being violated. 

Comments are welcome.

-- 
Rafael


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org