[lug] Linux Logic - Where do Files Go?

Michael J. Hammel mjhammel at graphics-muse.org
Tue Jan 23 09:52:10 MST 2007


On Tue, 2007-01-23 at 09:05 -0700, Warren Sanders wrote:
> Most of my frustration has been with only having
> Howto/readme instructions to the compiled versions and not the RPM
> versions.  

Software developers tend to put their compiled binaries and support
files in a temporary location for testing.  Their runtime environment is
often based on one (or more) distributions they happen to work with
and/or their history with Unix systems.  The old days used /usr/local
for applications, then /var because of sysadmin issues (mount point
management of multiple resource shares, etc.) and then /opt.  But then
the question of whether something is a "system" tool or an "application"
has to be answered.  If it's a "system" tool, doesn't it belong
under /usr or /usr/lib, or /etc, or /usr/bin?  What about /bin vs /sbin
vs /usr/bin?  Who decideds what should or should not go in those places?
Remember that most users will have /usr/bin in their path.  Most
sysadmin's automatically add /bin and /sbin.  So where should a
developers user-space program live?

What happens in the real-world is a developer picks an unobtrusive
location that makes some level of sense to the development practices and
expectations of how their users will access the software.  But they
usually develop based on software standards - protocols, databases, etc
- and not distribution standards.  It's a lot of extra work keeping up
with standards for your software *and* standards that have nothing to do
with how your software works.  

Distribution vendors then take that software and map them into larger
distributions based on support requirements.  How?  Most developers now
use Autoconf and friends and provide the --prefix option to specify
where the software is installed.  As a developer, I often set this
to /usr/local.  Distribution vendors often set this (or one of its
associated options) to something based on the FHS and/or LSB standards.
RPM provides the tools necessary to track where the files are stored so
that changes can be mapped correctly and (more importantly) dependencies
can be resolved.  Dependency checking is something that is almost never
included from developers source outside of linker failures during the
build phase.  For binary releases, distributions must track it or risk
binary incompatibilities with 3rd party packages that they distribute
outside of the main distribution.

In short (and in general - all rules are made to be broken), developers
provide mechanism while distributions implement policy.  At least when
it comes to where something lives on the disk.

FYI, many (well, some) RPM packages have readme files included with
them.  To find where they are located, do this:

% rpm -ql <packagename> | grep -i readme

To find a package name:

% rpm -qa | grep -i <blah>

where blah is some string you expect to be in the package name.  Want to
find out what TrueType fonts where instaled?  Try 

% rpm -qa | grep xorg

...
xorg-x11-fonts-truetype-7.0-3
...

% rpm -ql xorg-x11-fonts-truetype-7.0-3
/usr/share/X11/fonts
/usr/share/X11/fonts/TTF
/usr/share/X11/fonts/TTF/luximb.ttf
/usr/share/X11/fonts/TTF/luximbi.ttf
/usr/share/X11/fonts/TTF/luximr.ttf
/usr/share/X11/fonts/TTF/luximri.ttf
/usr/share/X11/fonts/TTF/luxirb.ttf
/usr/share/X11/fonts/TTF/luxirbi.ttf
/usr/share/X11/fonts/TTF/luxirr.ttf
/usr/share/X11/fonts/TTF/luxirri.ttf
/usr/share/X11/fonts/TTF/luxisb.ttf
/usr/share/X11/fonts/TTF/luxisbi.ttf
/usr/share/X11/fonts/TTF/luxisr.ttf
/usr/share/X11/fonts/TTF/luxisri.ttf

No readme file with this one, but at least you can see where the files
were installed.
-- 
Michael J. Hammel                                    Senior Software Engineer
mjhammel at graphics-muse.org                           http://graphics-muse.org
------------------------------------------------------------------------------
Burnout:  Attitudes are contagious.  Mine could kill you.




More information about the LUG mailing list