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

[Scott Doty]

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

  -Scott
CTO, Sonic.net, Inc.