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

Re: [RFC] DEP-6: Meta-Package debian/control field

On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote:
> So you're suggesting me to also do a "wicd" task.
> In experimental I have "wicd" depending on wicd-daemon + wicd-curses|wicd-
> gtk -- (it's a simple case, where the user might manually choose the 
> components, but it's good for the sake of exampling).
> A user having "wicd" installed now, and upgrading to experimental, might 
> want to remove one of the components:

>   # apt-get --purge remove wicd-curses

> This will also uninstall "wicd", and mark wicd-daemon and wicd-gtk for 
> autoremoval.

> I don't think we should escalate metapackages to tasks, sorry.

Special autoremoval handling of metapackages addresses this, without
meddling with the existing package relationship fields.  This could be done
with special handling of 'Section: metapackages', or by adding a new
'Metapackage: yes' field (as I think some would prefer based on comments on

Package: wicd
Section: metapackage
Depends: wicd-curses|wicd-gtk, wicd-daemon

# apt-get purge wicd-curses
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  wicd-curses* wicd*
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 57.3kB disk space will be freed.
Do you want to continue [Y/n]?

Those are exactly the correct semantics.  It makes no sense to remove the
depends of a metapackage *and leave the metapackage installed* - what
purpose would that serve?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: