What's the general rule for when to install a package from the official .deb
repositories, versus when to install with the language's package manager? The ones in the upstream repositories are frequently at least slightly out-of-date, but I also don't want to have my packages colliding with the "official" ones, and it seems that aptitude is going to force me to install the official ones in many cases anyway.
This is a difficult question to answer in generality.
The official .deb packages give you stability and full support by the Ubuntu community . If you don't need the latest version, you might be better off with this solution. You also have the package manager support for updates, removal, etc.
If you need support from upstream, or need the latest features, you are better off getting it from the distributions systems like CPAN , gem, pear, etc.
In my (admittedly not-to-vast) experience, language-specific package managers don't do anywhere as good a job as
.deb
ones in tracking dependencies that are totally outside the language's boundary (I'm especially thinking of dependencies on C-coded libraries which a package wraps for use in Python, Perl, Ruby, etc).If (say) a Pypi Python package
'barfoo'
requires some librarylibfoobar
in order to build the_bf.so
Python extension which the package uses, and needslibfoobar
to be at least at release5.2
, it's up to you to track down which.deb
supplies suitable releases oflibfoobar
(and you might not find one, if the Pypi package is tracking close to upstream's latest and greatest) -- and somehow keep track of it in case you uninstallbarfoo
later (so thelibfoobar
supplier gets "orphaned" and could/should be removed).I don't think that the problem of integrating Pypi/CPAN/etc with other package distribution systems can yet be considered a "solved" one. For minimal administration headaches, if you can get by with an official
.deb
(don't need latest-and-greatest feechurz &c), I think that would be advisable; at the other extreme, of course, for a package you do want to be super-updated (e.g., you're one of the package's upstream authors/maintainers;-), there is the option of keeping a fresh repo in whatever version control system the package uses (svn, hg, git, bazaar, ...) and keeping it built from sources. Pypi/CPAN/&c are "in the middle". Surely some of the time this middle way will be advisable, too.And, one option that might be considered is to build your own
.deb
package (based on either the Pypi/CPAN/&c one, or even on upstream sources) and keep your repository of such packages (for those packages for which you find official.deb
repos too poor or backwards). It's not much more trouble than installing otherwise (manually tracking outside-the-language dependencies) and would help with identification of "orphan packages" and the like (plus, if you publish your packaging, you can also help other people;-).I've truly been against using Aptitude to manage packages from another Package Manager. CPAN, Gems, Pecl, Pear, etc are Package managers for their respective languages. They are what you should default to - in my opinion - because that's what they are designed for. Not to mention most all of those handle upgrades and updates now (gem update, gem upgrade, etc). It would be like using yum to install Apache on your Ubuntu Machine.
That being said there are a few occasions when the Aptitude version reigns supreme. One such is when an installation of a module from a languages package manager fails (this is typically because of varying configuration issues) I rarely come across this issue - but when I do the correlating package from Aptitude does the trick.
Priority in my opinion Language Package Manager > Aptitude.