Task metapackages

[Matt Zimmerman]

On Fri, Oct 01, 2004 at 11:20:33AM +0200, Martin Pitt wrote:

> So what should be the purpose of such a desktop metapackage? As I
> understood it, it shall make it easy to setup a standard Warty
> installation on an e. g. woody system. But this is equally easy with
> installing the desktop task with aptitude. To make this even more
> transparent, I see two options:

As I explained in the previous thread, its purpose is to provide smooth
upgrades.  If we add a new package to the desktop seed for Hoary, users
upgrading from Warty should receive it as well.

> - Provide an ubuntu-desktop package which only depends on aptitude and
>   installs the task in its postinst script. Then the user is still
>   free to remove packages afterwards. However, IMHO this does not
>   really make much more sense.

It would not be wise to attempt to install packages with apt, dpkg and
friends reentrantly from a maitnainer script.  I don't think this would
provide intuitive behaviour, either; whenever the package would be upgraded,
it would undo the user's changes unless they find this mysterious package
and remove it.

> - Provide an upgrade-to-warty script which installs the task and can
>   do other necessary things like asking for local users and put them
>   into some groups (plugdev etc.). This is my favourite solution.

This solves a somewhat different problem, but is something we need anyway.
I've been discussing the specification off-list with Clint Adams.

It doesn't provide the semantics that we want for Ubuntu, though.

> The metapackage could also have the alternative dependencies. OTOH
> depending only on seeded packages does not help much either since you
> still cannot remove transitive dependencies without removing the
> desktop metapackage, too.

When the user makes an explicit choice to change the system, we must respect
that preference (the Golden Rule).  The difference is how we define when the
user has made an explicit choice to stray from the default:

If we depend on all desktop packages, then the user is straying from the
default when they uninstall any desktop package.

If we depend only on the seeded packages, then the user is straying from the
default only if they uninstall a seeded package.  They are free to rearrange
dependencies of desktop packages if they want.

> I still don't see why such a metapackage is useful at all (apart from
> upgrading, which I discussed above). What else do you have in mind?

The point is to provide an element in the packaging system which reflects
the user's high-level preferences regarding package selection and uses them
to provide intelligent upgrades.

-- 
 - mdz