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

[Michel Salim]

On Mon, Feb 23, 2009 at 11:31 AM, Ralf Corsepius <rc040203 at freenet.de> wrote:
> 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.
>
Agreed; I've not seen this use case clarified anywhere, though -- not
in the general packaging guidelines, and not in the Perl guidelines.
Given that it's popping up outside Perl, we probably need a general
guideline.

> 2) split out the plugin/add-on package into a separate package and let this
> spit-out package depend on the "base-package".
Seems overkill in this case, thus my wording of the proposed change.

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

Definitely. The question now is: do we amend the guidelines, or is
this an "obvious" use case that does not need clarification?

Thanks,

-- 
miʃel salim  •  http://hircus.jaiku.com/
IUCS         •  msalim at cs.indiana.edu
Fedora       •  salimma at fedoraproject.org
MacPorts     •  hircus at macports.org