kde packages to be removed 13.10 - > 14.04

[doctordruidphd]

About to do a dist-upgrade, but it is threatening to remove several kde packages that look important, including:

kde-window-manager kde-workspace kdebase-bin kdebase-runtime kdebase-workspace kdesudo

Doesn't look right.

$ apt-cache policy kdesudo
kdesudo:
Installed: 3.4.2.4+repack-2ubuntu4
Candidate: 3.4.2.4+repack-2ubuntu4
Version table:
*** 3.4.2.4+repack-2ubuntu4 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
100 /var/lib/dpkg/status

$ apt-cache policy kde-workspace
kde-workspace:
Installed: 4:4.11.6-0ubuntu1~ubuntu13.10~ppa2
Candidate: 4:4.11.6-0ubuntu2
Version table:
4:4.11.6-0ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
*** 4:4.11.6-0ubuntu1~ubuntu13.10~ppa2 0
100 /var/lib/dpkg/status

(This one probably came from the kubuntu-backports repository on 13.10, I'm guessing)

Now here is one that says it is going to upgrade:

$ apt-cache policy kde-runtime
kde-runtime:
Installed: 4:4.12.2-0ubuntu1~ubuntu13.10~ppa1
Candidate: 4:4.12.2-0ubuntu2
Version table:
4:4.12.2-0ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
*** 4:4.12.2-0ubuntu1~ubuntu13.10~ppa1 0
100 /var/lib/dpkg/status

Looks like for some reason there is a mix of kde-4.11 and 4.12; not sure why.
Any suggestions for resolving before I hit the Y button?

[vinnywright]

will they be replaced ?

you doing a "do-relece-upgrade -d" or just a "apt-get dist-upgrade" cause dist-upgrade dose not take ya to 14.04

VINNY

[doctordruidphd]

dist-upgrade dose not take ya to 14.04

It does if you rpl everything from "saucy" to "trusty" first...

Edit: At least it *should*.

[vinnywright]

It does if you rpl everything from "saucy" to "trusty" first...

Edit: At least it *should*.

right ,,,,should ,,,,,,I just did the "do relece-upgrade -d " on my 13.10 install and wint off just fine

so were the removed packages in the "new" or "upgraded" list apt-get gave ?

VINNY

[doctordruidphd]

This list of packages I gave is in the "To Be REMOVED" section.

I think what I may do is wipe the testing system, recopy 13.10 and try the do-release-upgrade option (which I forgot about before doing the rpl/dist-upgrade method).
Can't go any worse.

[vinnywright]

This list of packages I gave is in the "To Be REMOVED" section.

right ,,,,but thare is allso lists of new and upgraded ,,,that is the names of packages to be upgraded/replaced/added new ......

I think what I may do is wipe the testing system, recopy 13.10 and try the do-release-upgrade option (which I forgot about before doing the rpl/dist-upgrade method).
Can't go any worse.

right

VINNY

[doctordruidphd]

The packages I mentioned as being removed are not being upgraded or replaced, that's the scary part.
Will try the do-release-upgrade -d method & go from there.
May take a while, though.

[vinnywright]

The packages I mentioned as being removed are not being upgraded or replaced, that's the scary part.
Will try the do-release-upgrade -d method & go from there.
May take a while, though.

I think it took 30-45 min.

VINNY

[apachelogger]

It does if you rpl everything from "saucy" to "trusty" first...

Edit: At least it *should*.

Just to make this clear: apt-get dist-upgrade will not take you to trusty the same way as do-release-upgrade will.

dist-upgrade will do a package upgrade, meaning it will try to upgrade all packages you have available to their latest version. It will do this by only using information available in the package (namely the package relationship data... "a depends b, b recommends c" etc.), as part of the upgrade it will do fancy algorithmic magic on the information to decide what to remove/upgrade/newlyinstall/keep. It does not care whether your sources.list contains entires for saucy or trusty or hardy. It will quite simply take the data it has available and try to resolve all dependencies such that the most packages can be upgraded without having to remove too many core packages.

do-release-upgrade will roughly do the following:
- deactivate all repositories that are not official (e.g. PPAs)
- upgrade the official sources.list entries to the new version (e.g. trusty)
- refresh the apt cache
- if you do not have a *buntu-desktop package installed it will try to identify the meta desktop your installation belongs to (for example if you have unity and lightdm-gtk installed your system will be identified as ubuntu-desktop), the detected *buntu-desktop is then fake injected into the list of packages, such that you will again end up with *buntu-desktop installed after the upgrade. this is extremely important, as for example when upgrading from 12.04 you might loose the DM otherwise (we used KDM on 12.04 and are using LightDM on 14.04, but there is no actual package relationship between the two other than the kubuntu-desktop package).
- once your meta desktop has been found an additional set of transition rules may be applied (those vary from release to release, but for example those transition rules could remove one DM and make sure that another DM is installed)
- only once all of the above is done it will actually resolve the dependencies and tell you what needs to be removed/upgraded/newlyinstalled/kept
- if you agree the dist-upgrade gets started
- once the dist-upgrade is finished it will run apt-get autoremove along with some additional magic to detect deprecated and unused packages to clean up your systems somewhat.

so yeah, replacing all entires in sources.list will take you to trusty packages, it will not necessarily take you to a trusty system though (let alone a working one). do-release-upgrade is what you want to use for actual distro version upgrades *always*.

[doctordruidphd]

- once the dist-upgrade is finished it will run apt-get autoremove along with some additional magic to detect deprecated and unused packages to clean up your systems somewhat.

This is exactly the reason I try to avoid using options like this. I have a lot of customization, a lot of development packages for things that aren't part of "the system", etc., and the whole point in doing an upgrade as opposed to a "clean install" is to not have to completely reinstall/reconfigure all of that stuff.

Well the best way to do this is to try the do-release-upgrade and see what happens. With a system of around 48 gb it's going to take a while.

[doctordruidphd]

Now I remember why I didn't remember to use do-release-upgrade -d

Calculating the changes

Could not calculate the upgrade 

An unresolvable problem occurred while calculating the upgrade. 

This can be caused by: 
* Upgrading to a pre-release version of Ubuntu 
* Running the current pre-release version of Ubuntu 
* Unofficial software packages not provided by Ubuntu 

If none of this applies, then please report this bug using the 
command 'ubuntu-bug ubuntu-release-upgrader-core' in a terminal. 


Restoring original system state

Aborting
Reading package lists... Done    
Building dependency tree          
Reading state information... Done
Building data structures... Done 
=== Command detached from window (Tue Feb 25 12:11:29 2014) ===
=== Command terminated with exit status 1 (Tue Feb 25 12:11:29 2014) ===

[Snowhog]

Likely do to packages installed from your 'custom' repositories. Just a guess.

[doctordruidphd]

Likely do to packages installed from your 'custom' repositories. Just a guess.

No doubt. No distribution can (or would want to) keep up with development for specific applications, which often require newer versions of support libraries, etc.

So I think maybe, slow and painful as it is going to be, that working from a new install may be the best way to go for an LTS release. Don't know if I will still have that opinion a month or so from now when I get it all working.