Use based meta packages

[Jordan Mantha]

On Mon Jul 02, 2007 at 01:18:57PM +0200, Reinhard Tartler wrote:
> 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.

For meta-packages in the metapackages section, apt installs Recommends: as
well. This allows you to define essential (Depends: ) and non-essential
(Recommends: ) packages in the meta-packages. The non-essential packages
can be removed. The ubuntu-desktop package has been doing this, things like
firefox and OO.o are in Recommends. I think this makes meta-packages quite
attractive.
 
> 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.

It's pretty easy to make tasksel .desc files. You could ship a set of tasks
and install them to /usr/share/tasksel/ and tasksel/synaptic will pick them
up. No need to mess around with archives.

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

I haven't really had a chance to look into debtags much. To me it seems
intriguing, but not really very practical yet. Perhaps I'm not quit getting
it but I see lots of query and tag manipulation tools, but in the end, how
are users going to install packages? It sounds like work is being done to
integrate it with apt but it doesn't seem like it's there yet, from what I
read. Adept is the only package manager I could find that has support for
debtags. It does seem pretty cool though.
 
> 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!

This seems to be http://debtags.alioth.debian.org/ btw ( I had to google
for it).
 
> > 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.

Although I agree that making it super easy to create metapackages is a tad
scary, people already create 3rd party repos and people on the forums are
advocating equivs to create their own metapackages. Maybe having an easy,
and maybe more importantly controlled, tool to do this would help the
situation, maybe.
 
> I feel that debtags is far superior here than continuing to advocate
> even more meta-packages.

We only have 8 meta-packages in the metapackages section of the repos. I
don't really see there really being a big issue with putting more in there.
I could be entirely wrong, I hear ocassionally about a general dislike of
meta-packages, but I'm not sure if that's because they are used so much for
transitions and for normal packages. Perhaps some of the more experienced
devs could help me out with that :-)

Overall, IMO, it could really work to start out with some meta-packages for
common tasks or package groups because meta-packages are easy to create and
easy to use for the end-user. Then when debtags gets farther along we can
migrate to that. Any more thoughts? I'm pretty curious as to what "tasks"
people think would be useful. We've seen development tasks so far.

-Jordan