On Tue, Aug 31, 2010 at 08:24:30PM -0400, Leam Hall wrote:
Fedora curently steps outside of convention. What I'm advocating
returning to them. You're right that the /usr filesystem is somewhat
less critical to server boot and control that /bin and /sbin. However.
the applications that the server hosts, like apache and sendmail, should
not be there.
Leam, Fedora follows the convention established in the FHS. Vendor-provided
packages (that's us) are managed by RPM and install to the standard
hierarchy. Third-party packages install in /opt. This is absolutely the
correct approach for an integrated distro, and with modern package
management tools there's little disadvantage to it.
Seperate the server from what it serves. We should be able to totally
keep the application unconcerned about the base OS. Maintaining them
intermingled as they are now makes support that much more difficult.
So, Rocks Linux does this with its own bundled packages, to keep them out of
the way of the CentOS-based core OS. In my (unfortunately now considerable)
experience with it, this turns out to be a horrible, horrible nightmare when
they're all managed by the same RPM database.
And if we're talking about giving up RPM, that's a pretty drastic deviation
from Fedora and Fedora's history. Unless a lot of though and work were put
into doing it right, we'd probably end up reinventing the wheel, lumpily.
Something else might be done with multiple RPM databases, but that's also a
lot of refactoring, and probably the wrong tool for the job.
With isolation you don't have to worry about filesystem space
consumption, about changing the OS packages and hoping the upgrade
didn't whack the application's files anywhere, or about trying to
recover from a bad crash and remembering what all goes where at 3AM.
This isolation idea also goes against several other core Fedora packaging
rules, like using system libraries in preference to bundled ones.
Your idea may have merit, but it's really not a match for Fedora Server.
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences