meta packages for ubuntu-desktop

[Matt Zimmerman]

Please don't CC me on replies; I read the list.

On Tue, Dec 28, 2004 at 04:12:30PM +1100, Lex Hider wrote:

> On Wed, 2004-12-22 at 18:53 -0800, Matt Zimmerman wrote:
> > The original idea of these packages was to represent the seeds, and thereby
> > ease upgrading when the seeds change.  I'm a bit wary of creating a tree of
> > metapackages as a means of high-level package selection; this was found to
> > be suboptimal in Debian in the past.
> > 
> My idea was too represent the seeds better, not create anything new. The
> seeds all seem to be broken into sub-sections [the various headings] and
> my idea was to have packages that represent these.

The headings are purely informational; they don't generally represent
meaningful groups of packages that should be represented in the packaging
system.

> I do have to plead ignorance to the various issues, can you give a few
> more details to "found to be suboptimal in Debian in the past".

I don't have any references on hand; you'll need to do some searching.
Debian's "tasks" used to work this way.

> As far as a use case, think of someone who wants ubuntu-desktop without
> various parts.
> 
> e.g. I don't need OOffice and I don't have a printer. For the printer I
> have to rip out foomatic-*, cups*. Alternatively, someone may not want
> all the python stuff, but currently have to get rid of a large number of
> packages instead of a single ubuntu-desktop-python.
> 
> Or think of installing fairly minimal set and installing bits as you
> want them.
> 
> e.g. Install ubuntu-desktop-gnome gives me a gnome desktop. I decide I
> want to use a printer, install ubuntu-desktop-print which would have
> foomatic-* and cups*.

The guiding principle should be "KISS".  In the common case, users should
not even be aware of these metapackages; they're a background mechanism for
keeping the package selection up-to-date.  Users shouldn't generally install
or remove them unless they know exactly what they want, in which case they
can manage their own package selections.

Consider that even if you don't have a printer at the moment, CUPS is
potentially useful (you may need to print one day) and costs you almost
no resources to keep it.

OpenOffice is a bit of a special case, because it comes in essentially one
very large piece, but almost everyone wants it on their desktop anyway.

Currently, we offer two options:

 - use the default package selection (and optionally add to it),
   receiving automatic updates to the default selection when they
   occur

 - manage your own package selection, and take responsibility for keeping up
   with changes yourself (by reading release notes, mailing lists, checking
   the metapackages by hand, etc.)

What you're proposing is a third option, positioned between these two.  So
far, I'm not convinced that the tradeoff is in our favour: complexity (in
the packaging system and for the user) versus providing some users with a
"halfway" option for managing package selections.

-- 
 - mdz