View from the Trenches: Alternative Package Sources

If you know where to look (or if someone tells you where), you can find all the packages you want and need.

A couple of anonymous suggestions in response to last week's article inspired this week's installment of View from the Trenches. I had downloaded GAIM, the multiprotocol GTK instant messaging client and compiled it from source. This was a rather painful process, given all the -devel packages I had to chase down and install. One commenter suggested I try the usr local bin site to get pre-packaged GTK goodies for SuSE. I had no idea such a site existed, and I thought it would be a good idea to share not only this particular site but a number of sites that are helpful for finding Linux packages that aren't in the standard distribution.

I'll start with SuSE, as we've already touched on one site. In addition to usr local bin, which primarily offers GNOME/GTK stuff, we have PackMan, which has a number of packages ranging from games to MySQL drivers. Some of these appear to be a bit out of date, but there are a lot of them. As with a lot of SuSE stuff, some of this site is in German. You should be able to figure out things by the package names themselves, but if you get stuck, Babelfish can help translate. A number of multimedia-oriented packages are hosted on, including bttv, krecord, video4linux patches and documentation and linda, a client-server approach to a headless MP3 jukebox.

If you're dealing with SuSE, you're dealing with RPMs, and that brings me to one of the bigger cross-platform RPM sites, This Daniel Veillard project is hosted by the World Wide Web Consortium, with several mirror sites. Rpmfind has packages for almost everything you can think of for distributions ranging from ASP to Yellow Dog, both official and unofficial versions, as well as GNOME, KDE, Ximian, MySQL and blinux (Linux for the blind; it involves a kernel module, a serial port and a speech synthesizer, and it works quite well).

Another popular RPM site is, which is an indexing service as well as a small repository. Pbone knows where a number of the more obscure sites are, including all the different mirrors for a distribution, and thus is more apt (no pun intended) to find what you're after if it's hard to find. Pbone doesn't have near the bandwidth Rpmfind does, but it can be worth the wait.

Our next site is so popular it got blown right off the Internet: the Penguin Liberation Front. They've shut down open access, but if you Google for it you can get the cached page and find out where the mirrors are. PLF is a Mandrake repository of things that are not, for various reasons, included in the standard Mandrake distribution. I rather wish they had a mirror State-side, though; the ones they do have are European , and they seem rather slow from the West Coast).

For the Debian folks, punch up (of course) and have yourself a blast. This is not your ordinary package search engine; search for a program here, and it returns not links to individual packages, but the appropriate deb lines for your sources.list file. It also serves links so you can find what other packages are in the same repository and a rating as to the current status of the repository. (checked, down or unverified)., much like Pbone, is a meta-site; over 100,000 packages from over 300 different sites are in the search index. Two of my favorites are, for Pine, and, for Woody backports of Mozilla and Galeon. Woody backports of any number of packages are common things to see here.

Speaking of the old apt vs. RPM battle, you can, in fact, have your cake and eat it too. For those who like the idea of apt on an RPM-based system, we have APT-RPM, a port of apt to use RPM packages instead of debs, done by Conectiva. APT-RPM for Red Hat is available on; pointers to other versions can be found on the SourceForge links page. On the other hand, if you like RPM everywhere (including non-Linux platforms), check out OpenPKG. OpenPKG is, except for the bootstrapping process, heavily biased toward a source-based system in which you download the .src.rpm, check the GPG signature and then build the package from source (customizing along the way if need be). The resulting binary package, therefore, is tailored to your particular system. (FreeBSD users should find this seems familiar.) OpenPKG has over 400 packages, several mailing lists and its own bug database.

Red Hat people in particular seem to be cranky about updating their systems, for various reasons I won't go into here. So to wrap this up, I'll point to a few alternatives to up2date to help smooth things along. My favorite way of keeping a Red Hat system up to date is Ximian's Red Carpet. Ximian has been so kind as to split out Red Carpet from its other products and allow you to select only the OS channel, which seems to keep good pace with Red Hat's security update notifications. Ximian also supports Mandrake and SuSE, though I haven't run Red Carpet on either of them recently. Other updaters that seem to have community approval are yum (Yellow Dog Updater, Modified) and AutoUpdate. Yum requires a special repository server-side; AutoUpdate does not, but instead compares the names of the files on the configured site to the packages either in cache or in the local RPM database. A list of other RPM updaters, Red Hat and otherwise, can be found here.

So, now you know where all those packages you've been searching for lurk; go forth and install. For those of you wondering what happened to the series on conversion, I had some hardware issues and couldn't get to the fun part before press time. Those issues have been resolved and barring further encounters with Murphy, the series will continue next week. Such is life down in the trenches.

Glenn Stone is a Red Hat Certified Engineer, sysadmin, technical writer, cover model and general Linux flunkie. He has been hand-building computers for fun and profit since 1999, and he is a happy denizen of the Pacific Northwest.




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

And lets not forget for all your Debian stable backport needs :-)

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

If you are running Mandrake on the other hand, you have a wider array of options.

- Texstar's RPMs can be found in many servers.
- Penguin Liberation Front has all the things that can't make it in the distro because of law enforcement (DeCSS, etc)
- Mandrake Users Forum (the free one) has a nice FTP that mirrors a lot of packages
- All of Mandrake FTP sites have a directory called contrib, where contributions from users are stored. Hundreds of packages there.

Of course, the problem with these is that they mostly apply to Mandrake, but you can get the source rpms and build for your system most of the times.

One extra note... If you add those sites to urpmi (the great Mandrake tool that resembles apt-get), it will automatically install all requirements (dependencies) for your application and install them for you. Long live Mandrake!

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

Agreed. Urpmi, Mandrake's tool, is the most mature of the rpm tools simply because it has been around the longest.

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

Umm... well if you're after APT-RPM, I wonder why ALT Linux wasn't mentioned. It's quite capable repository and a special distro, very popular in xUSSR altogether.

Here are Freshmeat and DistroWatch project pages, and pbone knows about it too.

Michael `gvy` Shigorin
ALT Linux Team
mike osdn org ua

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

Compiling from source is certainly a more mindful process than simply clicking to install software over the net. However, it's also more secure, not to mention more customizable.

Of course, most people will not inspect the source code prior to compiling it, but the point is that you can whenever you want to. We all benefit when people do in significant numbers.

If instead you install a precompiled package, you give up that power of inspection, and you take on the risk that the software you've installed is not what you think it is, even if you later go to inspect what you may believe to be its source code. This is the situation which Microsoft users face all the time, and to my mind it's not enviable to be that na

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

I do agree with you partly. I sometimes prefer compiling, i have done LFS many times. But i do not enjoy compiling kde for 6 hours(on an xp1800+). As for your security concerns. Thats why we have md5sums. To verify file integrity. As well as someplaces use gpg and ssl to verify links securely.

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

And there are also scripts you have to run, when you compile yourself (./configure, makefile targets), that could contain nasty things.
So signatures and trusted source of packages is much more important IMHO.
You can hardly check every line in those files (at least not always, if you compile a lot).


Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

Unfortunately, signatures are usually used in very insecure ways on net.

For example, a web site will often have the source package and signature available from the same location. Anyone who could have compromised one can easily compromise the other. So that signature is absolutely worthless as far as security goes.

What people should really do is make signatures and files available from seperate servers (on seperate physical and logical networks, from different ISPs, preferably running different OS' secured differently, and perhaps one being an ftp server and the other a web server), that way there'll be less chance of both being compromised.

Another step forward would be to integrate the signatures with a web of trust, like gpg. But that really hasn't caught on nearly as much as simple md5s.


Re: View from the Trenches: Alternative Package Sources

Anonymous's picture is not as usable as is.

And despite the domain, .deb were also indexed.

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

As well there is for slackware pkg's
You can get Mplayer and packages that dont come with the basic install.

Re: View from the Trenches: Alternative Package Sources

Anonymous's picture

Good article!

But you seem to have missed out on one on the most useful apt-rpm, yum repositories out there for Redhat distributions:

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot