One of the Many PPA Problems
|
| Author | Content |
|---|---|
| Jeff91 Apr 29, 2012 10:39 PM EDT |
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 Apr 30, 2012 7:35 AM EDT |
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 Apr 30, 2012 8:02 AM EDT |
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 Apr 30, 2012 8:28 AM EDT |
@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 Apr 30, 2012 8:56 AM EDT |
> 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 Apr 30, 2012 11:31 AM EDT |
@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 Apr 30, 2012 2:58 PM EDT |
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 Apr 30, 2012 3:49 PM EDT |
@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. |
| Jeff91 Apr 30, 2012 5:49 PM EDT |
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 |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!