Is it OK to mix rpm and source based installations on a production web server? Or is it preferable to either completely go with one or the other way?

thanks a lot


Package management is always the best way to go, purely because it allows you to deal with a single modular entity. Packages make installing and upgrading servers considerably easier. It allows you to reason about your servers easier; you know what version of a particular piece of software is installed. You can be sure that you're running the same binary across several different servers.

I would highly recommend that you learn how to generate RPM packages for any piece of software you install. It might slow you down initially, but you'll reap the rewards later.

  • Thanks for the insight. You mean create rpm from a source and then install that rpm? Is that common practice? – cherouvim Oct 19 '09 at 19:58
  • The practice of building local packages is somewhat common. I know I have a couple packages I have built for the servers I maintain. – Zoredache Oct 19 '09 at 20:08
  • Absolutely. And you can have patches in the SRPM to make those little modifications you wound up needing so you don't have to rediscover the trick all over again. – retracile Oct 19 '09 at 20:11
  • I install all my software via packages, building them myself if I need to. I don't install any software from source. It's just not worth the pain. – David Pashley Oct 19 '09 at 20:13
  • If you ever plan to scale it is imperative that you do any package customizations (or new packages) using rpms. You can easily setup your own repository of custom packages using createrepo so that you can distribute changes to all your systems easily. – Brian C. Lane Oct 23 '09 at 4:08

I would say pick a path and keep it consistent...Personally I prefer package manager since it's a lot easier to maintain and script against..


The thing to remember about source packages is that you MUST watch the security mail lists on your own and watch the upstream provider in case any critical bugs are discovered. You may need to be prepared to backport fixes to your current system if you aren't ready to upgraded when upstream decides to make a change that breaks something. When using packages from the distributor you can be a bit more relaxed about security issues and trust them to find and fix security issues and release updates as required.

If there is a business reason to use a newer version, then you need to decide if the effort and risk is worth it. You just need to make sure you are prepared to handle things like security yourself.

Like David mentioned, you really should consider learning how to build your own packages. If you have more then one system a properly built package can be reused on your second system. It can be reused on your testing box. That way you don't have a particular package compiled with one option on system a, and a different set of options on system b.

  • Thanks for the info. I do have more than one box to maintain but the problem is that they are very different in terms of cpu architecture and distro. I guess that the reusability of the generated rpm does not apply in this case, right? – cherouvim Oct 19 '09 at 20:18
  • If you have different distros, or different releases of the same distro then you don't get much from reusablity. Of course I question why you are supporting many distros/releases, but that is a separate topic. I still think building your own packages for a single system is preferable to mixing source-installs and package installs on the same system. Once you get the hang of it building/backporting packages tends to be pretty easy. – Zoredache Oct 19 '09 at 20:46
  • Well, as long as they still use the same package format (or if fact there are ways to install rpm/deb on the other kind of system), just make source packages, and build on the targets. You have to handle lib versions anyways. Also, you likely can find someone who has already bulit the package version you need, and use theirs (PPA's are an example for Ubuntu). – Ronald Pottol Oct 19 '09 at 22:03

If you have a single server it is generally ok to do everything to make it work and do a full / backup. Only if you keep documentation of your actions (/etc/motd is good enough) . Altough messy, mixing rpms/cpan/deb/custom builds is not that bad unless you have to duplicate the machine. For example my personal laptop is a total dump:) Every time i do dist-upgrade somethings breaks but it's acceptable - i'm the only user. If you have a couple machines that perform the same functions and you need them to perform very predictibable mixing different type of install modes will get you in a lot of trouble. You have to learn how to build rpms/deb and maybe set your own in-house yum repository.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.