[lsb-discuss] RE: [lsb-futures] Re: [Lsb-desktop] Re: KDE representation

[Banginwar, Rajesh]

Ted,
	The idea that Dirk mentioned was we loosen that requirements and
let application distribute non-LSB conforming libraries. But as Stuart
mentioned, that may not be possible for all libraries due to their
dependencies etc. 

Thanks,

-Rajesh

> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso at mit.edu]
> Sent: Wednesday, August 17, 2005 9:14 AM
> To: Banginwar, Rajesh
> Cc: Matt Taggart; Olaf Schmidt; lsb-desktop at freestandards.org; lsb-
> discuss at freestandards.org; lsb-futures at freestandards.org
> Subject: Re: [lsb-futures] Re: [Lsb-desktop] Re: KDE representation
> 
> On Tue, Aug 16, 2005 at 02:06:59PM -0700, Banginwar, Rajesh wrote:
> > LSB also requires that these distributed library need to be LSB
> > compliant. Why not loosen that restriction? So with this, LSB will
allow
> > the application developers to allow distribute any non-LSB library
and
> > not require them to be LSB conformant. App A depends on libraries
B,C
> > and D. B and C are covered in LSB and hence not a problem for App A;
but
> > library D is not covered, but shipped with App A making sure the
library
> > is available and installed at /opt hierarchy.
> >
> > I am not sure whether libQt license allows this or not. If it does,
then
> > we can consider this as a potential solution to this problem.
> 
> This works, as long as:
> 
> 1)  Library (D) is also LSB-conforming, and
> 
> 2) Library (D) is installed in an application-specific directory, and
> the application modified to use a wrapper script which sets
> LD_LIBRARY_PATH before calling the real executable.  (Or the
> application is compiled using rpath.)  Installing Library (D) in the
> system library directories would of course lead to Windows-style
> DLL-hell, as different applications need different (incompatible)
> versions of the same shared library.
> 
> 						- Ted