On Wed, Sep 01, 2010 at 03:36:54PM -0400, Leam Hall wrote:
Fedora packages third-party apps like Apache. So your point is taken
it supports what I've been saying. ;)
The packages are provided by the vendor -- Fedora, us. They're not
third-party in that sense. This has been the standard interpretation of the
FHS since forever.
No, not giving up RPM. But fixing the SRPMs so that the third party
stuff gets installed in /opt.
What's "third party stuff"? Where would you suggest to draw the line?
Apache? APR? Glibc?
How are dependencies of these things managed? Since the dependencies go in
the same RPM database, what's the value of having things separated?
Until those system libraries have an application dependancy that
precludes OS upgrade. I agree that the application should use a system
bit if the system bit is in the OS core itself. However, if the
application needs libXYZ and we don't package libXYZ in the core then
they can keep their own versions and their own coherency.
What happens if two packages need libXYZ? What happens when it's added to
the core ? What if two packages need it? What if there's a security problem
in a library? Again, this opens up a whole bunch of packaging issues that
are _already addressed_ by Fedora.
The other point I'm hoping to get across is that just because a
rule has been made doesn't mean it's the best answer for mixed
environments. Fedora rules so far seem pretty desktop centric and RH-Linux
But this particular approach is taken by Debian, Ubuntu, RHEL, SUSE, Gentoo,
Slackware... I can't think of a Linux distribution that doesn't follow it,
so it seems weird to call it myopic or desktop-centric.
Most of the SysAdmins I know work with 3-5 different OS's, 2-4
versions of each, a few applicance OS versions, and take care of
applications 'cause the developers don't have a clue. The simpler we can
make that job for them the more valuable Fedora Server would be, to me.
That's a fair argument, but I don't think it's an argument for Fedora
Server. It's an argument for trying some new thing -- which you're welcome
to do, but I don't think it's a productive discussion *here*.
> Your idea may have merit, but it's really not a match for
If there's consensus on the latter, that's fine. I have not heard that
though, nor have I really heard anything that convinces me /opt and
separate filesystems are not the way to go. If you can convince me,
great! It means you've been able to help me learn more.
If you want to discuss this particular idea further, please mail me
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences