here are three reasons for waiting for a standard debian package:

stability, stability, stability.

seriously. the debian QA process is awesome, and the maintainers for the initial package tend to know a lot more about the quirks of building their specific packages than most people do. (at least, they know a lot more than i do!)

Of course, this isn't to say that for a particular package where you really need a new feature that's being offered (or you need a patch applied), you shouldn't spend some time building and packaging (and testing!) the new version yourself.

But yer probably better off focussing your time on those few particular packages that you plan on self-maintaining because you need the new versions or patches explicitly, while letting debian take care of providing you with a stable platform with all the other packages.

just my 2 cents... i'd be interested to hear which packages people actually tend to self-maintain like this, though.

> stability, stability, stability.

Maintainability.

Debian metadata includes subtle feature, like "provides".

MTA's know they are alternatives for each other, and software that needs an MTA installed locally can see that it is there.

Sure in any specific case you can usually do as well, or better, by hand.

But with something like Apache2, there are a whole host of packages that bring in modules for Perl, PHP, even entire MVC systems like Catalyst. These depend on existing packages, and require others, and also set themselves up nicely in /etc/apache2/mods-available (see earlier articles by Steve on how to use these folders) when installed.

If you build by hand you are unlikely to be able to match the integration of all these components, and when one has a critical security issue will you have the time to rebuild it? (The answer is no - trust me). Will you even be subscribed to the relevant security mailing list?

The complexity of modern systems is such that making it all work together seamlessly is well beyond the one admin at my company. We could employ lots of admins, or we could work with the people cooperating to do this as a team, the Debian developers.

I'm an experience admin, but for various (mostly silly) legacy reasons, I did a sendmail build from source on one of our Redhat based mail servers - and suddenly I discovered that sendmail compiling is (can be!) complicated! Having eventually installed a consistent set of Berkeley like databases, and found a set of compatible compilation flags, and now moving it all to Debian, and prepackaged Postfix, and hoping all those sendmail security announcements before that happens aren't really THAT important.

That are some good reasons to use debian packages.

I see the pros about using debian packages with testing, security and maintenance... it can spare you a lot of time. (time that I almost do NOT have ;) )

But what if I want to use an Apache, PHP or MySQL version that is not packaged whit de Debian version I use...