[Fedora-packaging] Packaging clarification regarding bash-completion scripts

[Ralf Corsepius]

Michel Salim wrote:
> One of my package, bti, now ships a bash-completion script, which
> needs to be installed in /etc/bash_completion.d/ . It seems that the
> expectation is that installing bash-completion should automagically
> enable all applications that provide completion scripts, and so
> existing packages should own /etc/bash_completion.d (rather than
> depending on it).
> 
> Bearing that in mind,
> 1. Should this be included in the guidelines? Currently, none of the
> use cases match: to guard against renaming, and if two unrelated
> packages install files to a common directory
> 
> I'm proposing "3. Optional dependency. If your package has a
> non-essential feature that is not significant enough to split off to a
> separate subpackage, then you may choose not to Require: the package
> needed for that feature, but instead own the relevant directories."
> 
> Are we still not allowing optional dependencies (suggests / recommends
> / hints)? Otherwise, for such features, the dependency should be
> suggested rather than silently ignored.
> 
> 2. Some packages install files in /etc/bash_completion.d without
> either requiring bash-completion or owning the directory:
> - darcs
> - mercurial
IMO, this qualifies these packages as "sloppily packaged", read minor 
"bugs".

> Depending on how this is resolved, we'd need to open bugs against them
> with the recommended solution.

To me, this is another incarnation of the "plugin module" issue, ie. 
packages install an add-on to a package, but do not strictly depend on 
the base package they provide a plugin for.

For those cases, 2 approaches exist:

1) let all packages which provide such a plugin own the directory, they 
install a plugin/add-on to (This is the approach, which is being applied 
for packaging perl-modules)

This approach, however is only functional when all packages providing 
such "plugins/add-ons" obey such a convention.

2) split out the plugin/add-on package into a separate package and let 
this spit-out package depend on the "base-package".


However, both approaches, are only fully functional when all packages 
providing such "plugins/add-ons" obey such conventions.

Ralf