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
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
