[lsb-discuss] Regarding doubts in LSB support for HPLIP.

Wichmann, Mats D mats.d.wichmann at intel.com
Tue Nov 8 12:59:23 UTC 2011


Till, you've managed to get the first post through since the servers went
away - I didn't even know the
lists were back yet!!!


On Tue, Nov 8, 2011 at 12:51 AM, Till Kamppeter <till.kamppeter at gmail.com>wrote:

> Sorry for the late answer, I was on the Ubuntu Developer Summit all last
> week. Now I am back and yesterday I have recovered the OpenPrinting web
> server.
>
> I am CCing also the LSB mailing list to get helps from the people who are
> making the LSB framework.
>
> More inline.
>
> On 10/31/2011 05:06 AM, Kumar, Sanjay wrote:
>
>> Hello Till,
>>
>> While going forward in making HPLIP as LSB compliant, we have some
>> doubts. Please help us in providing the clarification on the same.
>> Thanks in advance for all the help.
>>
>> 1) LSB package does not contain the latest versions of libraries which
>> are LSB compliant.
>>
>> e.g LSB compliant *libcupsimage.so* does not contain latest function
>> calls, e.g *cupsRasterReadHeader2* function is not present in
>> */opt/lsb/lib/libcupsimage.so.**2*, however HPLIP makes use of this.
>>
>>
> Make sure you use the newest LSB (4.1).
>

The LSB SDK "stub" libraries (/opt/lsb/lib/*) contain only those symbols
which are part of the agreed ABI for that version.  To put what Till said
in a
different light, you should use the oldest version of LSB which suits your
needs (as in providing the symbols needed), but no older; 4.1 is the latest.

There is a set of analysis tools which can look at an "application" (rpm
package, single binary, directory tree, whatever) and provide an analysis
of this situation - use of non-LSB interfaces and libraries, version
compatibility info, etc.  (lsb-app-checker).  I believe the LSB repositories
are still unavailable however, so there might be a bit of a delay.

If you find there is no version of LSB that provides what you need, then
let the project know what's missing (mailing list post is fine, preferred
method was filing a bug but I don't know if that's been restored yet),
AND take a look at whether an LSB-mode build can code around the
absence of those functions.   The aforementioned lsb-app-checker can
submit a report for you if you click a checkbox, that's another way to
provide usage information back to the project.




>
>  2) Following shared libraries are not present which are needed by HPLIP.
>>
>> a) libnetsnmp.so
>>
>> b) libcrypto.so
>>
>> c) libdbus.so
>>
>> d) libusb.so
>>
>> e) libcups.so (present but very old version)
>>
>> f) libcupsimage.so (present but very old version)
>>
>>
> Make sure you use LSB 4.1 and if the libraries are too old or still
> missing, link the desired ones statically.
>
>  Is there any plan/update on having LSB compliant versions of these
>> libraries from the vendors? Because if the package is statically linked
>> with 3rd party libraries then package will lose the advantage of using
>> always latest library.
>>
>

see after next question for a comment on these



>
>>
> The distribution vendors do not issue LSB packages of additional libraries.
>
> You get an LSB-compliant package if you link the libraries statically. If
> the package once works it is not a big problem if the statically linked
> libraries are not the newest ones. The communication protocols provided by
> the libraries do not change so quickly, and as you issue a new driver
> version every 2-3 months, you can make the new version's LSB package always
> with updatyed statically linked libraries.
>
>  3) Sometimes 3^rd party latest libraries cannot be built in LSB
>> environment (lsbcc etc), e.g latest version of *libdbus* (1.0.8) failed
>> tobuilt with lsbcccompiler. Only (0.1.12) version could be built with
>> lsbcc, just in case we want to link it statically.
>>
>>
> Can someone from the LSB developers help here, so that the HPLIP
> developers get libdbus 1.0.8 built under LSB?
>

If some details are provided on the failures, I'm sure they'll be looked at.
libdbus is actually on the roadmap; libcrypto has not been since it's part
of the openssl suite, which is excluded for various reasons I don't want
to rehash here (for ssl support, libnss3 is provided
in LSB, see here for some conversion notes:
https://fedoraproject.org/wiki/FedoraCryptoConsolidation).  The other
mentioned libraries have not, I believe, been requested for inclusion.



>
>  4) LSB looks mostly to be a coding/building standard. Does it assure
>> same quality on all distro’s (particularly, from different vendors)?
>>
>>
> Can someone of the LSB developers answer this? Thanks.
>



"Quality", on the surface, is not a problem solved by LSB.  However,
as part of the compatibility exercise, the fact that interfaces are
described functionally, rather than by version-of-library, means tests
can be coded which test for that functionality.  To the extent such
tests exist in the LSB suite, one could consider this a kind of quality
promise - in order to be certified conforming, a candidate distro will
have to have passed tests for the LSB functionality.  [the caveat is
that test coverage varies by library, from "very extensive" in the case
of glibc all the way to "almost none" for certain libraries]



>
>  5) The major differences we see across distro’s are in CUPS, GS, etc
>> which are not LSB compliant and which are being used heavily by HPLIP.
>> Many issues are caused because of these components like *GS versions
>> (e.g versions 9.00 and 8.71). So *how much LSB would help us
>> in reducing testing efforts and how safe is this to skip testing of HPLIP
>> on
>> every LSB compliant distribution?
>>
>
> Can someone of the LSB developers answer this, too? Thanks.



There's no simple answer to this question in general, as it varies by
situation.
Given this description - if you're running into problems with non-LSB
components -
it seems somewhat unlikely.  The most conservative view (again - it varies
by case) is "LSB provides a base for building an application which will
deploy
on a wide range of systems but does not remove the need for testing on
those systems".  My guess without knowing the circumstances would be
that you could over time develop a minimal test suite which spot-checks
familiar
problem areas and would not have to do a full test on everything.  But it's
only a guess without knowing the precise details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lsb-discuss/attachments/20111108/2b96e1cc/attachment.html>


More information about the lsb-discuss mailing list