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

Bug#609255: KDE upgrading


On trečiadienis 12 Sausis 2011 16:44:31 Julien Cristau wrote:
> I'm afraid I'm a bit concerned about this metapackage stuff.  Why
> weren't the metapackages from lenny kept around to help upgrades, with
> kde and kde-core depending e.g. on the new kde-standard metapackage?


First of all, what was the situation in Lenny:

1) kde [1] was a metapackage which depended on a bunch of other metapackages 
(i.e. the whole KDE). The list includes kde-core.
2) kde-core [2] is a metapackage which depended on 3 other metapackages 
(including kdebase metapackage, see below).

Now what happended in Squeeze:

1) kde mepackage got removed. You might consider kde-full [3] metapackage as a 
rough equivalent of the old kde metapackage, yet it's not entirely true. 
`aptitude install kde` no longer works in Squeeze.

2) kde-core got removed. kde-plasma-desktop is a new rough equivalent of kde-
core metapackage. `aptitude install kde-core` no longer works in Squeeze.

3) However, we have still kept kdebase metapackage in Squeeze [4]. As you see, 
it depends on kde-plasma-desktop. So basically the transitional metapackage 
for kde-core is there. But ...

... transitional metapackages for metapackages only delay the inevitable to 
the next Debian release, they do not solve anything. If I understand 
correctly, that was one of the problems DEP6 [5] was supposed to solve. 
Unfortunately, it has been REJECTED.

In short, "auto" status is very damaging for "normal" packages pulled via 
metapackages. Suppose the user installed the whole KDE with `aptitude install 
kde`. So now the whole KDE got auto-installed status except the metapackage 
itself. As soon as any KDE component is removed, kde metapackage has to be 
removed and then the rest of KDE is also subject to autoremove.

kdeaddons (KDE 3) is no longer in KDE 4. So kde metapackage will have to be 
removed upon upgrade to Squeeze potentially "autoremoving" part of KDE which 
are not pulled in by kde-plasma-desktop (kept back by transitional kdebase). 
What's more, kdebase Recommends kde-standard so default setup (with 
autorecommends ON) should even stay at kde-standard level. Yet aptitude/lenny 
will most probably keep more packages due to bugs in marking some auto-
installed as manually installed under the hood. `apt-get autoremove` is not 
default behaviour anyway, yet it could be considered as posing some problem 

If we kept kde metapackage, the problem would simply be delayed to Wheezy. 
IMHO, it's much better to do disruptive changes now when major upstream KDE 
upgrade is happening.

FWIW, kde metapackage name was a too obvious choice. Yet the package used to 
pull so much useless stuff that barely anybody needed. We dropped and replaced 
it with the names that force a user to actually choose what (s)he wants (or at 
least think about it). There is no good reason to keep legacy 'kde' 
metapackage around for another 2 years because then it would still remain the 
'default' choice by users rather than conscious choice between kde-standard 
and kde-full or even kde-plasma-desktop.

[1] http://packages.debian.org/lenny/kde
[2] http://packages.debian.org/lenny/kde-core
[3] FWIW, I consider kde-standard to be successor of kde metapackage even if 
it installs much fewer packages.
[4] http://packages.debian.org/squeeze/kdebase
[5] http://dep.debian.net/deps/dep6/
[6] http://people.skolelinux.org/~pere/debian-upgrade-testing/test-20101213-

Modestas Vainius <modestas@vainius.eu>

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: