[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Package variant selection policy using meta packages

Dear developers,

I’d like to get opinions on whether it is ok to (ab)use meta packages,
alternative dependencies and conflicts to provide package selection
policy features to our users that are not supported otherwise.

Here is an example (and it is the use case that I am considering):

Haskell libraries are always shipped in three different packages:
      * libghc-foo-dev ← The library itself
      * libghc-foo-prof ← Extra data only used when profiling code
      * libghc-foo-doc ← Documentation.

Let’s look at -prof only(for -doc the same scheme would be useful).
Users tend to fall into one of three classes:
     A. Users that, if they have foo-dev installed, always also want
        foo-prof installed.
     B. Users that want to manually decide for what packages they want
        the -prof package and for what package not.
     C. Users who don’t want any -prof package around.

Currently, we only really help user B. If user A installs foo-dev there
is nothing that ensures that he gets foo-prof installed as well.

So my idea is to have a meta package for each use case. Note that this
meta package should _not_ have to explicitly list all libghc-*-*
packages, as it should not have to be changed when we add a new Haskell
library (and it would make the testing migration even harder). So this
should work (names just working titles, of course):

I create three meta packages, named i-want-all-prof-packages,
i-want-some-prof-packages, i-want-no-prof-packages. The package
relations are then:

  Conflicts: i-want-some-prof-packages i-want-no-prof-packages

  Conflicts: i-want-some-prof-packages

  [no special relations]
  Depends: libghc-foo-prof | i-want-some-prof-packages | i-want-no-prof-package
  Conflicts: i-want-no-prof-package

Clearly, only at most one of the three policy packages will be
      * If i-want-all-prof-packages is installed, this means that the
        dependency of foo-dev implies foo-prof, as intended.
      * If i-want-some-prof-packages is installed, then the dependency
        of foo-dev is always fulfilled, so the user can decide what he
        wants or what not.
      * If i-want-no-prof-packages is installed, then the foo-dev
        dependency is fulfilled, but no -prof package can be installed.

So all three use cases are supported, and our users happy.

What do you think – should Debian employ such methods, or not? If not,
why not?


PS: The existence of i-want-some-prof-packages, which has no
dependencies, ensures that installability in general is not impaired, so
this scheme would have /no/ bad effect on the testing migration.

Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: