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

[Samisa Abeysinghe]

We seem to need one more change at Axis2/C level, that is to make the 
repo path compile time configurable. It is only runtime configurable at 
the moment.
That is a very simple fix anyway.

Thanks,
Samisa...

Samisa Abeysinghe wrote:
> 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


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