On Mon, Feb 23, 2009 at 11:31 AM, Ralf Corsepius <rc040203(a)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
> 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
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
2) split out the plugin/add-on package into a separate package and
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
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?
miʃel salim • http://hircus.jaiku.com/
IUCS • msalim(a)cs.indiana.edu
Fedora • salimma(a)fedoraproject.org
MacPorts • hircus(a)macports.org