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

Re: Package variant selection policy using meta packages



Hi Haskell Group,

the following proposal was did not get a lot of negative feedback on
d-devel (so, by Debian standards, it means that we can probably do
it :-)):

Am Samstag, den 22.12.2012, 13:17 +0100 schrieb Joachim Breitner:
> 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:
> 
> i-want-all-prof-packages:
>   Conflicts: i-want-some-prof-packages i-want-no-prof-packages
> 
> i-want-no-prof-packages:
>   Conflicts: i-want-some-prof-packages
> 
> i-want-some-prof-packages:
>   [no special relations]
>   
> libghc-foo-dev:
>   Depends: libghc-foo-prof | i-want-some-prof-packages | i-want-no-prof-package
> libghc-foo-prof:
>   Conflicts: i-want-no-prof-package
> 
> Clearly, only at most one of the three policy packages will be
> installed.
>       * 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?

So, do you think that our Users would benefit from this scheme? Is it
understandable? Or not worth the effort?

And what should the policy packages be called?

Greetings,
Joachim

-- 
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: