Making Packager-Friendly Software (O'Reilly)

Posted Apr 7, 2005 13:02 UTC (Thu) by horen (guest, #2514)
Parent article: Making Packager-Friendly Software (O'Reilly)

Since becomming a sysadmin in 1988 (SunOS/3.2), I've learned to differentiate between system and "extras" files, and use different types and methods for installing them.

When I install a system -- either a desktop workstation or a server -- I install only the minimum set of RPMs necessary for the host to successfully arrive at bootlevel 3 (or 5). That's it for packaged software.

Afterward, I install everything else -- all "extras" -- from source, compiling/configuring for /usr/local operation (on a server, I place BIND, Sendmail, and a few others in the same locations as their RPM counterparts). Thankfully, some packaged-binaries conform to this model, such as Firefox and Thunderbird.

In a networked environment, all "extras" are installed on file-servers and /usr/local is made available for automounting.

In a standalone environment, I believe that it is no less important for "extras" to be placed in /usr/local (i.e., installed/compiled/configured from source), in order to prevent them from being overwritten by system upgrades or automatic updates. Even better is to place /usr/local on its own partition or disk.

I have used this model in both academic and commercial settings, and it has never failed me. YMMV.

Making Packager-Friendly Software (O'Reilly)

Posted Apr 7, 2005 14:00 UTC (Thu) by NAR (subscriber, #1313) [Link]

I have used this model in both academic and commercial settings, and it has never failed me. YMMV.

So you do fetch the source/patch, compile, install, optionally remove not used files and update configuration files every time there is a new version/fix for a security bug instead of waiting for the distributor to package the new/fixed software and install it with an "apt-get-like" mechanism, don't you? Well, it might be faster and more secure, but I wouldn't want to do it as a desktop user...

Bye,NAR