Use based meta packages

[Reinhard Tartler]

Jono Bacon <jono at ubuntu.com> writes:

> I just wanted to get your views on something. I think it could be useful
> to have pre-configurations for different uses. ...
>
> So, imagine I install "kubuntu-kde-devel", it would pull in
> build-essential, kdevelop, qt-dev, unit testing software, kdbg and
> various other tools to allow KDE development, but also configure Firefox
> so there is a toolbar bookmark to the Qt online docs as an example.
> Imagine a use case was "embedded development" - the package could
> install and configure cross-compilation tools, which are traditionally a
> real pain to set up.

I think this brings up the old discussion of 'meta-packages' in
general. meta-packages are empty packages, which are only used to
conveniently convince apt to install a set of packages. This can be seen
commonly in packages like 'ubuntu-desktop' and friends and works
generally quite well.

Now imagine a meta-package 'kubuntu-kde-devel'. If a user removes one
package the meta-package depends on, which might be on purpose, or by
installing another package which conflicts against one package of
"kubuntu-kde-devel's" dependents, apt decides that the meta-package needs
to be removed as well, because its dependencies cannot be fulfilled
anymore. This is correct, but surprises users, because they don't want
to 'loose' the 'kubuntu-kde-devel' functionality.

An improvement to this would be to use tasksel. Tasks are written in the
package indices on the archive AFAIUI. tools like tasksel or aptitude
can be told to install all packages in a given task. Later, if the user
decides to remove a package, no surprise come anymore.

The problem here is that it is quite hard to install custom tasks. Users
generally don't setup their own archive software to fiddle with the set
of tasks in the package indices.

A more sane approach IMO would be to use Debtags. There you could invent
for your specific domain your own vocabulary of tags, and mark packages
appropriately. You don't need meta-packages or tasks here, you need to
define the set of tags (or the single tag) a package must have in order
to be installed. The advantage here is that you can easily install your
own tag sources. We could provide 'official' debtags sources in the
archive, and let users provide their own tags for existing packages.

There are a number of frontends for editing tags on packages. The most
convenient is perhaps GoTagging, which is a Webbased frontend. Enrico
Zini has others as well!

> If this is doable, it could open up Ubuntu and Kubuntu to really
> interesting use cases, which are a pinch to set up. Then imagine we
> allow the community to create these meta-packages (with a process to
> ensure quality), we could have a little GUI application which could
> browse a bunch of these use cases and install the relevant package for
> that use case.

I don't feel very comfortable with this idea. This effectively means that
we encourage people to run their 3rd party repositories, which means
that users would have to carefully check the repositories contents
(there might be other packages than 'just' the meta-packages) and the
gpg id, a task too complicated for the average user.

I feel that debtags is far superior here than continuing to advocate
even more meta-packages.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4