Bug#609255: KDE upgrading
On Sun, Jan 16, 2011 at 09:38:35 +0100, Francesco P. Lovergine wrote: > On Thu, Jan 13, 2011 at 08:37:53PM +0100, Julien Cristau wrote: > > > > (Non-exhaustive) testing shows that this allows the upgrade to proceed > > and get an acceptable (or even good) result, even when kwin styles are > > installed. These style packages are left installed after the upgrade, > > but that shouldn't hurt anything since they're basically cruft which can > > be cleaned up afterwards. > > > > Uhm I don't know if the following is expected. Shouldn't kwin dist-upgrade > directly at this point? > You don't seem to have the new kde-window-manager yet. Cheers, Julien signature.asc Description: Digital signature
Bug#609255: KDE upgrading
On Thu, Jan 13, 2011 at 08:37:53PM +0100, Julien Cristau wrote: > > (Non-exhaustive) testing shows that this allows the upgrade to proceed > and get an acceptable (or even good) result, even when kwin styles are > installed. These style packages are left installed after the upgrade, > but that shouldn't hurt anything since they're basically cruft which can > be cleaned up afterwards. > Uhm I don't know if the following is expected. Shouldn't kwin dist-upgrade directly at this point? frankie@klecker:~$ LANG=C sudo apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: bitlbee kwin 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded. frankie@klecker:~$ LANG=C sudo apt-get install kwin Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: kwin : Depends: kde-window-manager but it is not going to be installed E: Broken packages frankie@klecker:~$ LANG=C sudo apt-get install kde-window-manager Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libkdecorations4 libkwineffects1a The following packages will be REMOVED: kwin The following NEW packages will be installed: kde-window-manager libkdecorations4 libkwineffects1a 0 upgraded, 3 newly installed, 1 to remove and 1 not upgraded. Need to get 2615 kB of archives. After this operation, 3777 kB of additional disk space will be used. Do you want to continue [Y/n]? -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
On Thu, Jan 13, 2011 at 16:54:11 +0100, Julien Cristau wrote: > Hi, > > adding deity@ to cc as I need help with this. Context: the upgrade path > from kde3 (in lenny) to kde4 (in squeeze) is non-trivial, and I'm hoping > we can still improve it. It's very, very late though, so maybe not. > tl;dr: we came up with a plan that seems to work. Now on to the details. First problem with the upgrade path: - kdesktop doesn't get removed until too late Solution: - remove the kdesktop alternative from libkonq5's Depends Second issue: - kwin doesn't get removed, it has a higher score than kde-window-manager Solution: - reintroduce an installable kwin package in squeeze, pulling in kde-window-decorator, and conflicting with compiz-kde << 0.8.2 - drop Conflicts/Replaces kwin from libkdecorations4 and libkwineffects1a - replace the unversioned Conflicts on kwin from kde-window-manager, make it a versioned Conflicts or Breaks instead (Non-exhaustive) testing shows that this allows the upgrade to proceed and get an acceptable (or even good) result, even when kwin styles are installed. These style packages are left installed after the upgrade, but that shouldn't hurt anything since they're basically cruft which can be cleaned up afterwards. Thanks to Sune, Modestas and David for the help with this. Cheers, Julien signature.asc Description: Digital signature
Bug#609255: KDE upgrading
On Thursday 13 January 2011 18:50:15 Julien Cristau wrote: omething like that, and make the conflics versioned? > > David suggested to remove the kdesktop alternative from libkonq5's > Depends. With this, konqueror doesn't get removed anymore. I think that's a good idea. to remove that alternative. > kdebase > still does, though, because apt decides to keep kwin instead of > installing kde-window-manager (at least as far as I can read the log). > Full log at http://people.debian.org/~jcristau/apt-kde-2.txt ..and kwin package actually contains a *shared* library that other packages *link against* (yes, it is wrong, but that's what we have to live with now). ...maybe (gross hack) a transitional kwin package that has conflicts on whatever links the library? (especially the relevant lenny compiz stuff, the rest is just kwin plugins) /Sune -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
On Thu, Jan 13, 2011 at 18:32:17 +0100, Sune Vuorela wrote: > On Thursday 13 January 2011 16:54:11 Julien Cristau wrote: > > > So apt wants to keep kdesktop, while the new kdebase-workspace-bin > > Breaks it, kdebase-bin Conflicts with it, as does libkonq5-templates. > > > > ModaX, can you clarify why these Breaks/Conflicts are there? > > libkonq5-templates has is a full subset of kdesktop/lenny > > kdebase-workspace-bin contains /usr/bin/kcheckrunning > ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605135 ) > > I don't see why kdebase-bin is there. kcheckrunning might have been in there > earlier. but I'm not sure. > > It is btw pretty crucial to get rid of kdesktop. It contains a kdesktop > executable, and more important, a kdesktop autostart file. > > > Does anyone see a way out of this? (Let me know if I can provide more > > information.) > > a idea could be to provide a transitional kdesktop package depending on > plasma-desktop or something like that, and make the conflics versioned? > David suggested to remove the kdesktop alternative from libkonq5's Depends. With this, konqueror doesn't get removed anymore. kdebase still does, though, because apt decides to keep kwin instead of installing kde-window-manager (at least as far as I can read the log). Full log at http://people.debian.org/~jcristau/apt-kde-2.txt Cheers, Julien signature.asc Description: Digital signature
Bug#609255: KDE upgrading
On Thursday 13 January 2011 16:54:11 Julien Cristau wrote: > So apt wants to keep kdesktop, while the new kdebase-workspace-bin > Breaks it, kdebase-bin Conflicts with it, as does libkonq5-templates. > > ModaX, can you clarify why these Breaks/Conflicts are there? libkonq5-templates has is a full subset of kdesktop/lenny kdebase-workspace-bin contains /usr/bin/kcheckrunning ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605135 ) I don't see why kdebase-bin is there. kcheckrunning might have been in there earlier. but I'm not sure. It is btw pretty crucial to get rid of kdesktop. It contains a kdesktop executable, and more important, a kdesktop autostart file. > Does anyone see a way out of this? (Let me know if I can provide more > information.) a idea could be to provide a transitional kdesktop package depending on plasma-desktop or something like that, and make the conflics versioned? /Sune -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
I forgot one point... > So apt wants to keep kdesktop, while the new kdebase-workspace-bin > Breaks it, kdebase-bin Conflicts with it, as does libkonq5-templates. > In the end apt *does* end up removing kdesktop, but: Investigating kdesktop Package kdesktop has broken dep on kdebase-bin Considering kdebase-bin 148 as a solution to kdesktop 7 Removing kdesktop rather than change kdebase-bin Try to Re-Instate kscreensaver Investigating kscreensaver Package kscreensaver has broken dep on kdebase-bin Considering kdebase-bin 148 as a solution to kscreensaver 4 Removing kscreensaver rather than change kdebase-bin Try to Re-Instate kdeartwork Investigating kdeartwork Package kdeartwork has broken dep on kscreensaver Considering kscreensaver 148 as a solution to kdeartwork 2 Removing kdeartwork rather than change kscreensaver and so on. So the packages that were removed (or not installed) because of the kdesktop conflict aren't pulled back in when kdesktop is finally removed. Cheers, Julien signature.asc Description: Digital signature
Bug#609255: KDE upgrading
Hi, adding deity@ to cc as I need help with this. Context: the upgrade path from kde3 (in lenny) to kde4 (in squeeze) is non-trivial, and I'm hoping we can still improve it. It's very, very late though, so maybe not. On Thu, Jan 13, 2011 at 00:53:14 +0200, Modestas Vainius wrote: > 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. [snip] So today I set up a lenny vm. Chose the kde desktop in lenny, standard setup (then installed openssh-server and screen so I could get stuff done) [0]. # sed -i s/lenny/squeeze/ /etc/apt/sources.list # apt-get update [...] # apt-get dist-upgrade [...] 727 upgraded, 595 newly installed, 40 to remove and 3 not upgraded. 40 to remove doesn't sound too bad from a first look, but. One of those removed packages is kdebase, which from ModaX's 3) above is the one kde metapackage that is kept between lenny and squeeze. Others include kdeartwork, kdebase-bin, kdeutils, konqueror, kscreensaver, ... which I assume are supposed to stay around and get upgraded. I thought adding back the kde and kde-core metapackages would help (depending on the new kde-full and kde-standard, respectively), it turns out not to change anything. The problem, as far as I can tell from the apt logs[1], is here: Package kdesktop has broken dep on kdebase-bin Considering kdebase-bin 6 as a solution to kdesktop 7 Added kdebase-bin to the remove list Fixing kdesktop via keep of kdebase-bin Try to Re-Instate kdebase-bin Investigating kdebase-bin Package kdebase-bin has broken dep on kdebase-bin-kde3 Considering kdebase-bin-kde3 -1 as a solution to kdebase-bin 6 Added kdebase-bin-kde3 to the remove list Package kdebase-bin has broken dep on kdebase-runtime-bin-kde4 Fixing kdebase-bin via keep of kdebase-bin-kde3 [...] Package kdebase-workspace-bin has broken dep on kdesktop Considering kdesktop 7 as a solution to kdebase-workspace-bin 4 Holding Back kdebase-workspace-bin rather than change kdesktop Investigating kdebase-apps Package kdebase-apps has broken dep on kdebase-bin Considering kdebase-bin 6 as a solution to kdebase-apps 4 Holding Back kdebase-apps rather than change kdebase-bin Investigating kdebase-workspace Package kdebase-workspace has broken dep on kdebase-workspace-bin Considering kdebase-workspace-bin 4 as a solution to kdebase-workspace 4 Holding Back kdebase-workspace rather than change kdebase-workspace-bin So apt wants to keep kdesktop, while the new kdebase-workspace-bin Breaks it, kdebase-bin Conflicts with it, as does libkonq5-templates. ModaX, can you clarify why these Breaks/Conflicts are there? Does anyone see a way out of this? (Let me know if I can provide more information.) [0] http://people.debian.org/~jcristau/kde-status [1] http://people.debian.org/~jcristau/apt-kde.txt Thanks, Julien signature.asc Description: Digital signature
Bug#609255: KDE upgrading
Hello, 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? No. 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 [6]. 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- lenny-squeeze-kde-summary.txt -- Modestas Vainius signature.asc Description: This is a digitally signed message part.
Bug#609255: KDE upgrading
Hello, On trečiadienis 12 Sausis 2011 17:10:33 Francesco P. Lovergine wrote: > On Wed, Jan 12, 2011 at 03:44:31PM +0100, Julien Cristau wrote: > > On Wed, Jan 12, 2011 at 14:34:12 +0100, Francesco P. Lovergine 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? > > > > Francesco, care to share details of your upgrade? What packages were > > installed pre-upgrade, log from apt, …? > > I could provide a long dpkg log, but I upgraded with more rounds of > apt-get due to some intermediate failures (not kde related), the whole > workflow is quite not easy to be understood. That log would be useless then. Both apt and aptitude do many stupid decisions when it comes to recovering from dpkg failures. Demonstrate problems with clean upgrade (or at least only with KDE related failures), then we could actually try to fix those problems. Btw, I tested upgrades on the system which had the whole KDE 3.5 installed by 'kde' metapackage a couple of months ago. The end result was NOT that bad. IIRC, some not so much significant stuff from kdemultimedia or kdeedu got autoremoved wrongly but that's acceptable. -- Modestas Vainius signature.asc Description: This is a digitally signed message part.
Bug#609255: KDE upgrading
On Wed, Jan 12, 2011 at 02:34:12PM +0100, Francesco P. Lovergine wrote: > It happened to me upgrading my first kde desktop today, which resulted > in a completely not working KDE enviroment: after logging in, a scrambled > desktop background appeared and nothing else. Of course, I did > a whole upgrading, because that (multi-user) desktop > had many different desktop environments installed and I did not > put on hold kde 3.5 packages, because it was pointless for me. > > I would add a big WARNING for users at upgrading time about that. > I got a working environment by installing 'kde-full' after completing the > whole > dist upgrade. Maybe, this is not evidenti enough by current release notes, I > would stress the following concepts: > > - The KDE env will be *ruined and unusable* just after a plain > dist-upgrade. > - Installing kde-full or kde-standard is *mandatory* and > it should happen just after upgrading. File a bug against the metapackage with the detailed log upgrade log, please. A general 'it did not work for me' without details here won't get this solved. The upgrade from kde3->kde4 is not perfect but following the notes from the release note it works (TM). Ana -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
On Wed, Jan 12, 2011 at 03:44:31PM +0100, Julien Cristau wrote: > On Wed, Jan 12, 2011 at 14:34:12 +0100, Francesco P. Lovergine 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? > > Francesco, care to share details of your upgrade? What packages were > installed pre-upgrade, log from apt, …? > I could provide a long dpkg log, but I upgraded with more rounds of apt-get due to some intermediate failures (not kde related), the whole workflow is quite not easy to be understood. /me too does not understand why a clean upgrade path has not been provided for the required meta-package. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#609255: KDE upgrading
On Wed, Jan 12, 2011 at 14:34:12 +0100, Francesco P. Lovergine wrote: > It happened to me upgrading my first kde desktop today, which resulted > in a completely not working KDE enviroment: after logging in, a scrambled > desktop background appeared and nothing else. Of course, I did > a whole upgrading, because that (multi-user) desktop > had many different desktop environments installed and I did not > put on hold kde 3.5 packages, because it was pointless for me. > > I would add a big WARNING for users at upgrading time about that. > I got a working environment by installing 'kde-full' after completing the > whole > dist upgrade. Maybe, this is not evidenti enough by current release notes, I > would stress the following concepts: > > - The KDE env will be *ruined and unusable* just after a plain > dist-upgrade. > - Installing kde-full or kde-standard is *mandatory* and > it should happen just after upgrading. > 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? Francesco, care to share details of your upgrade? What packages were installed pre-upgrade, log from apt, …? Cheers, Julien signature.asc Description: Digital signature
Bug#609255: KDE upgrading
It happened to me upgrading my first kde desktop today, which resulted in a completely not working KDE enviroment: after logging in, a scrambled desktop background appeared and nothing else. Of course, I did a whole upgrading, because that (multi-user) desktop had many different desktop environments installed and I did not put on hold kde 3.5 packages, because it was pointless for me. I would add a big WARNING for users at upgrading time about that. I got a working environment by installing 'kde-full' after completing the whole dist upgrade. Maybe, this is not evidenti enough by current release notes, I would stress the following concepts: - The KDE env will be *ruined and unusable* just after a plain dist-upgrade. - Installing kde-full or kde-standard is *mandatory* and it should happen just after upgrading. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
