The Linux FSS is a beautiful thing, as are SRPMS.

Scott Doty scott at
Thu Sep 2 17:34:08 UTC 2010

  On 09/01/2010 12:36 PM, Leam Hall wrote:

> 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.

I've used Unix since 1991 and Linux since 1992 and I'm telling you, 
that's not what /opt is for.

/opt is analogous /usr/local, but with each application -- or in some 
cases, groups of applications -- in its/their own directory.  Both /opt 
/and /usr/local are for your own in-house builds of apps -- we use it 
extensively on our servers, because we have a lot of in-house software 
that we maintain.

If you're building and maintaining your own (say) Apache, it makes 
perfect sense for you to put it in /opt.  But consider:  how would you 
like it if your httpd binary -- in /opt -- was overwritten by "yum 
update"?  I'm guessing you would not be happy with that, because nobody 
would be happy with that.

I'm a survivor of various filesystem standards.  (Did you know that 
binaries for various Net servers used to live in /etc ?)  So I'm here to 
tell you know, the current FSS is fine, fine business.  That's not to 
say it couldn't use some improvement -- for instance, I'd love to have 
an easy way to change the java symlinks in /etc/alternatives with some 
sort of ncurses tool.  (Or the same for any large application suite for 
which we have /etc/alternatives.)  But I know that Internet servers 
provided by the distribution live in /usr/sbin, and it's been that way 
since before we stopped putting "in." in Net server binary filenames.

> 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.

I disagree, and point out that the Linux FSS isn't just a RH thing, it's 
used all across Linux distributions.  Also, I should mention that Fedora 
itself is community-governed, so if you want to depart from the Linux 
FSS, you only have to convince a certain X number of people that it 
should be changed...but count me out of that, I think both /opt and 
/usr/local need to remain off-limits to the distribution.

>   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.

This is not only unfair to the developers, it's also the way _we_ used 
to do things, maybe around 8 years ago.  The world has moved on:  if 
you're not using (say) Fedora's httpd on your Fedora servers, I have to 
wonder what it is that you don't like about Fedora's Apache?  I use it 
on two of my personal servers that are running Fedora, and I have no 
problem with them.

Back in the bad-ol' days, if a distro-provided package didn't do its job 
right, we'd grab the sources and build our own version, since that was a 
lot easier to keep up with all the issues we were tracking.  Nowadays, 
it's a simple matter (in Fedora) to grab the SRPM and come up with a 
change that can be passed upstream to whomever is interested in it.

>   The simpler we
> can make that job for them the more valuable Fedora Server would be, to me.

On our network, we (at work) make all changes in SRPMS, and keep the 
resulting binary rpms in our own repos, to update our 200+ servers.  
Though they are a mix of CentOS 5.5 and RH 7.3 servers, the principle is 
the same as Fedora, albeit with different build host guests running in 
kvm virts.  I finally took the time to learn how to manage SRPMS (since 
the operations guys had done this long ago), and found the learning 
curve really wasn't as steep as I thought it would be.

Even to look as sources, I use Fedora's "yumdownloader --source X" 
feature, where "X" is the package name.  That way, I not only get the 
pristine tgz of the original sources, but I can see what patches folks 
with the Fedora Project have added.

Finally, I should mention that there's another advantage to using an 
SRPM for a vital server application:  so far, I haven't found an SRPM 
that won't build working binaries for both Fedora _and_ CentOS 5.5.  
This is a beautiful thing for packages that aren't (yet?) in CentOS, but 
can be found in Fedora.

Take care, and happy Thursday. :)

CTO,, Inc.

More information about the server mailing list