…is yes, rather Edgy.
Yesterday:
apt-get --download-only dist-upgrade # grab pkgs at work
apt-get dist-upgrade # go home and do the dist-upgrade
apt-get dselect-upgrade # WTF?!? I had a lot of held-back pkgs?!?
# Seems dselect-upgrade is more aggressive...
apt-get install xserver-xorg # Funny apt-get tried to sneak away
# my xserver-xorg (I lost it after dist-upgrade)
aptitude dist-upgrade # Hmmm, perhaps even better than
# dselect-upgrade...
Today: (I ran out of Smart 3G prepaid credits last night :/)
apt-get update # Hmmm, apt's rather verbose lately
# with locales and stuff
apt-get install kubuntu-desktop # Heh, somehow I figured that was missing...
After all this, I seem to have a completely-upgraded Kubuntu system now (verified by doing {dist-,dselect-,}upgrade again,) despite the lack of a proper updating tool for Kubuntu (Ubuntu has its own Update Manager.) Still, FWIW I had to go through some hoops along the way (like all those multiple dist-upgrade invocations; I’ve done that before (twice) on the Breezy -> Dapper path, but thrice on Dapper -> Edgy? Just, wow…) but I got to learn some new stuff too (like pairing perlis and elric (my new 3G phone) via Bluetooth on the console.
However, if I was in a hurry, I would have just e2mkfs‘d my partitions and started over. But then again, would I have had to move from Dapper to Edgy if I wanted to do that install dance all over again?
Granted, the upgrade process needs some improvement: either elevate `dist-upgrade’ capabilities to an even higher, godlike status, or make use of a different upgrader (dselect and aptitude does seem to have the upper `edge’ compared to apt-get…)
I guess there’s still some advantage of me not following the Edgy development process too closely (SoC, getting a new job, and school makes such a busy mix
but I’d love to jump back again in Feisty, now that I do have the means to follow development more closely.
Update: Looks like the dist-upgrades corrupted my swap partition, preventing me to do hibernates. A mkswap, followed by the subsequent edit in /etc/fstab and a reboot, fixed that.
Update 2: Seems hibernate still doesn’t work (although suspend to RAM works absolutely fine.) A look of the resume process seems to show similarities between this bug, but I’ve yet to confirm.
Update 3: I have found a workaround to this hibernate issue by rebooting with the `ro’ flag removed from the kernel command line, then adding a `resume=/dev/hdaX’ or `resume=UUID=XXXXXX’. Upon further investigation, it also appears that my swap partition doesn’t get corrupted at all; what seems to happen is that the kernel or `swapon’ doesn’t recognize it on the next boot, thus failing with an `Invalid argument.’