[lsb-discuss] LSB 4.2 Project Plan, Rollup bug

Robert Schweikert rschweikert at novell.com
Tue Mar 8 05:21:29 PST 2011



On 03/07/2011 06:37 PM, Craig Scott wrote:
> A few comments from an ISV perspective:
> 
> (1) Qt itself has an optional dependency on libXfixes. It does this by dynamically loading the library at runtime rather than linking directly to it. It would seem wise to try to include libXfixes in the LSB spec so that the lib Qt tries to pull in is guaranteed to be compatible.

Sounds reasonable to me. I've added it to the project plan.
> 
> (2) If there is going to be an uplift of Qt version, I'd suggest moving to at least Qt 4.5.3 if possible, not just 4.4. The main reason for this is that there are some commercial packages (eg Maya from Autodesk) which specifically list 4.5.3 as the Qt version to build against for development of plugins for their packages. From my personal perspective, I'd also say that moving to 4.4 still leaves Qt too far behind to be useful. Qt has moved so far so fast that we would still be bundling more recent Qt libraries with our applications. Also note that a number of interfaces and useful features appeared in 4.6, so please keep this in mind as a marker for future uplift considerations as well.

Yup, the old "the LSB Qt is too old" problem. As you know we do orient
the LSB along enterprise distros. SLES 11 SP1 ships Qt 4.4, thus an
uplift past 4.4 is unlikely. The LSB is a "trailing" not a "leading"
standard. Although we have talked about the possibility of taking more
of a leading role. However, considering distributors sensitivities,
deprecation policy etc, that would be extremely difficult.
> 
> (3) libtiff is a particularly useful library for the imaging community (and it is not a small community - just think of the medical imaging field for starters). The tiff format is one of the more commonly used and some of their image sizes are huge. Computation on these images is also often very intensive, hence the use of linux is relatively common in this field from what I understand (definitely the case on the research side anyway). Unfortunately, I think some distros use different soname versions to others which is making the current situation somewhat dicey if your app links to libtiff. Having LSB define a spec for libtiff would certainly clarify and simplify things. There's a good chance that a symlink for the correct sonamed lib would be the remedy for systems that differed from whatever the LSB spec ended up stating.

Added to the wiki

Robert


-- 
Robert Schweikert                           MAY THE SOURCE BE WITH YOU
Novell-IBM Software Integration Center                LINUX
Tech Lead
rschweikert at novell.com
rschweikert at ca.ibm.com
781-464-8147

Novell
Making IT Work As One


More information about the lsb-discuss mailing list