*tap* *tap* *tap*

Matthew Miller mattdm at mattdm.org
Thu Sep 2 00:07:45 UTC 2010


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 as 
> 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 Fedora
> 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
> myopic. 

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 Fedora Server.
> 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
off-list. Thanks.


-- 
Matthew Miller <mattdm at mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences


More information about the server mailing list