On Mon, Feb 23, 2009 at 11:31 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> 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@xxxxxxxxxxxxxx Fedora • salimma@xxxxxxxxxxxxxxxxx MacPorts • hircus@xxxxxxxxxxxx -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
