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