[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
> 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
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
>> 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
Given this description - if you're running into problems with non-LSB
it seems somewhat unlikely. The most conservative view (again - it varies
by case) is "LSB provides a base for building an application which will
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
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...
More information about the lsb-discuss