[wsf-c-dev] [C] Adhering to FHS & use of LD_LIBRARYPATH]

[Samisa Abeysinghe]

I was looking into what needs to be done to move the logs to /var/opt 
and also calling ldconfig form rpm spec file.
There were some code changes required at Axis2/C level, to configure the 
log file location at compile time. Earlier it was only configurable at 
run time.
I have fixed the code in Axis2/C and now we can configure the code to 
write the log to where we want.

So we are all set to create an RPM that adheres to FHS. SanjayaR is 
working on the RPM spec file and we can hopefully have a test RPM early 
next week.

By the looks of it, I feel that we can easily implement the same for deb 
packages as well.

Thanks,
Samisa...

Hi All,

Even though this closely applicable for the C development, I think this still 
has some applicability to other technologies as well.

Adhering to FHS
==========
http://www.pathname.com/fhs/

This has been designed to be used by Unix distribution developers, package 
developers, and system implementers. So the software we develop should be FHS 
friendly if we want it to be run in larger/enterprise deployments.

For example, /usr and /opt are treated as shareable static directories. There 
for these directories can be mounted read-only and shared across different 
systems to save storage. Only place you can guarantee to have variable 
(dynamic) files is /var. Again except for /var/run and /var/lock other 
directories under /var are shareable. Also if we haven't integrated with a 
Linux distribution the only place we can install our software is the opt 
hierarchy (/opt, /etc/opt, /var/opt). There are designated directories to 
store executable, libraries, configuration files, log files, etc.

Will our software work under these conditions? Samisa is currently evaluating 
this with Sanjaya R for the C stuff.

LD_LIBRARYPATH
==========
I have seen instances that we are depending on this. This is not recommended 
except in development time. 

http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

"LD_LIBRARY_PATH is handy for development and testing, but shouldn't be 
modified by an installation process for normal use by normal users; see ``Why 
LD_LIBRARY_PATH is Bad'' at http://xahlee.org/UnixResource_dir/_/ldpath.html 
for an explanation of why. But it's still useful for development or testing, 
and for working around problems that can't be worked around otherwise"

The recommended approach is to;

At the end of the library installation if a conf file which has the path to 
the library should be placed in /etc/ld.so.conf.d and the command ldconfig 
should be executed. 
According to the man page the path can be passed even in the 
command line but that will not survive across an OS upgrade or another library 
installation. Also it is stated that "ldconfig  creates, updates, and removes 
the necessary links and cache (for use by the run-time linker, ld.so) to the 
most recent shared libraries found... etc".

I think this is a simple fix for the installation.

Standard Distributions and third party libraries
=============================
Every Linux/Unix distribution comes with a very comprehensive set of 
libraries. We should analyze these and have a very strong reason to use some 
thing else when we are doing that. This give us a better chance to survive 
across OS upgrades and reduce the level of coupling we have with other 
libraries.

Also I think we should think about providing proper RPMs, DEBs, etc (and host 
them in repositories) so that installation tools can rightly figure out the 
dependencies and provide a very smooth installation experience. Ideally I 
should be able to start the server without having to modify any thing soon 
after installing the software.

One think I don't like is having to ship 100 third party libraries (which 
takes up about 80% of the distribution) get a reasonable application working. 
These packaging tools help us to overcome this problem to a great extent.

Thanks
Sanjaya
-- 
Senior Software Architect
WSO2 Inc. www.wso2.com
Office: +94 11 242 4303 ext 213
Mobile: +94 77 738 2548

"Oxygenating the Web Service Platform."
==================================================
“Opportunity is missed by most people because it is dressed in overalls and 
looks like work.”
- Thomas Edison

_______________________________________________
Architecture mailing list
Architecture at lists.wso2.com
https://www-lk.wso2.com/cgi-bin/mailman/listinfo/architecture


-- 
Samisa Abeysinghe : WSO2 WSF/PHP
"http://wso2.org/projects/wsf/php?WSO2 Web Services Framework%2FPHP - Open source PHP extention for providing and consuming Web services in PHP"