Advanced

From Lucid To Precise: An Upgrade Diary

Posted by lordpenguin on · 9 comments
www.thepowerbase.com; By Dean Howell
Mail this story
Print this story

This upgrade is directly inspired from an article by Joey Sneddon over at OMG! Ubuntu. Joey upgrades a 10.04 installation to 12.04 and gets some really great results. The jump from Lucid to Precise is a significant one, so seeing his success, minus the loss of his wallpaper, is great news for those of us that are able to stick with this Jurassic release.

This upgrade is directly inspired from an article by Joey Sneddon over at OMG! Ubuntu. Joey upgrades a 10.04 installation to 12.04 and gets some really great results. The jump from Lucid to Precise is a significant one, so seeing his success, minus the loss of his wallpaper, is great news for those of us that are able to stick with this Jurassic release. I mean let’s face it, it just works. The fact that Lucid ‘just works’ is its greatest achievement. I remember when I was younger, a working computer was not such a big deal. My machines were routinely broken because I was trying this or that, or testing something just for the sake of it. That behavior has changed with age. My argument for using Ubuntu over other distributions is a simple, philosophical one; Do you need something to do or do you need to do something.

I wrote recently about the long-term viability of Ubuntu 10.04 and how you can still benefit from using it as your main machine or later releases. After all, this release still has 1 year of updates left for desktop users, and 3 years of updates on the server. Those server updates can easily be had past the desktop edition’s EOL as well. Ubuntu claims to support the desktop edition for 3 years, though lots of softwares are left behind collecting version dust in your Gnome menu Thanks to Launchpad, there are quite a few PPAs to sate your need for up-to-date software too. Thanks to these PPAs, I’m able to use Shotwell over F-Spot, and up until recently I was able to run the most current release. With many softwares moving to GTK3, it’s the end of the road for updates on 10.04 regardless of another year of updates.

Full Story

  Nav
» Read more about: Story Type: Editorial; Groups: Linux, Ubuntu

» Get new stories by e-mail: nightly or as they are published

« Return to the newswire homepage

  Related stories
» More like this

Comments (9)

Jeff91 ·
Look at his software sources on page 2 - it is no wonder he had issues with the upgrade. If you install software from a million different untrusted/unofficial sources how on earth can Ubuntu be allowed to upgrade without causing an issue with something the user has done?

That being said - this is one of the many issues with PPAs. It is the reason the Bodhi team and I work so hard to backport current software versions to our users - so they don't have to go through adding piles of potentially unsafe/messy PPAs to their systems.

~Jeff
number6x ·
The best way to upgrade with many third party sources is to, first, comment out all third party sources. Upgrade only the distributions core sources.

Then, one by one, in the days and weeks following the distribution's upgrade, edit each third party source checking for compliance.

Some third parties keep the release name or number in their source and create a newly named source after the upgrade. Some third party sources keep the same name, yet update the software. Others are not maintained and will never be updated with newer software. You sometimes just keep running the same old stuff.

It can take months for some third party maintainers to update after an upgrade, if ever.

Be patient.

gus3 ·
Quoting:It can take months for some third party maintainers to update after an upgrade, if ever.
Yet another reason to just DIY, especially if the software package has security concerns (e.g. firewall module, credentials management).
number6x ·
@gus,

That's good advice. Third party sources can open up a security risk.

Getting source code from the project itself and doing the step source code install can be safer.

It isn't that difficult to type:

configure make sudo make install
jdixon ·
> It isn't that difficult to type :.. configure make sudo make install

Ack. No. Don't do that.

Make a package which can be installed via your normal packaging tools. That way you can remove it easily if the need arises and potentially share it with others.

I believe checkinstall has the capability to build Debian compatible packages via the make process. I've used it created Slackware packages before.
lordpenguin ·
@Jeff91 You guys over a Bodhi are great, and you're right! Ubuntu needs to do a better job at backporting, especially for LTS releases.

To be fair, you should notice in my article that none of the issues that arose were the result of software from those PPA channels. The issue was with Compiz. I later discovered issues with the latest Nvidia driver, Compiz and my 6100go chipset.

I resolved it be installing the Nvidia v173 driver. So, for the recordm everything is working fine.

- Dean Howell
dinotrac ·
Nice to see that I'm not the only one who gets pissed off at having to choose between:

1) Doing a full release upgrade in order to the version of a specific package (or packages) that I want, or 2) Getting them by "other" means

I put LMDE on my wife's workstation -- and it doesn't have that problem. It's a rolling release, and individual packages do get upgraded over time. Sounds like Bodhi does something equivalent.
caitlyn ·
@jdixon hit a very important point. Building packages is not an arcane art. If you can compile and install from source you can build packages. In fairness, Debian packages are more difficult than rpms or Slackware packages, but even they aren't exactly difficult. The whole point of a package manager is to have a tool to track and manage your software in one place. If you defeat that the odds of having problems later go up exponentially.

@Jeff91 also makes an incredibly important point: the more third party sources you use the more difficult things become. This is where you can run into package conflicts and upgrade errors galore. I don't know if apt-get/aptitude/synaptic have anything like yum priorities so that conflicts can be avoided by ranking the importance of repositories. Slackware Apt (slapt-get/gslapt) does have a similar mechanism, though it isn't nearly as flexible as yum-priorities when handling a relatively large number of repos, as in more than 2 or 3.

One of my biggest complaints about both Red Hat and SLES/SLED, both enterprise operating systems used in business, is the relatively small size of their repositories and the large number of commonly used business packages that are not directly supported. This forces an unfortunate dependency on third party repositories. For example, Red Hat doesn't package any of the popular CMS (content management systems) so I end up having to enable EPEL on most of the web servers I support. This obviously applies to the free Red Hat clones and Oracle Linux as well. This is where Debian and Ubuntu really should shine since they have huge repositories, yet here we have an example where a large number of third party repos still created a huge mess for an Ubuntu user. Unfortunate.
Read the whole comment
Jeff91 ·
Thats funny - I've tried my hand at both RPMs and DEBs and ultimately ended up building on Ubuntu cause I found DEBs far easier than RPMs to create :)

And yes - apt does support putting different "priorities" on repos.

~Jeff

Post a comment

A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.

Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help

Sign up and post (it is free)  or  Log in and post