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

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Mar 7 16:33:12 PST 2011

lsb-discuss-bounces at lists.linux-foundation.org wrote:
> A few comments from an ISV perspective:

Cool, thanks.  We have some infrastructure for this stuff, let
me point it out to people who are willing to get in and edit

First, we have a "Futures Tracker", which actually breaks down
into two separate displays, both linked from here:


unfortunately at the moment one data table to drive the
"Uplift tracker" doesn't have the data it needs to pull anything
useful, we should have that fixed pretty soon.

> (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.

Fixes was once on the list, but nobody seemed to have a compelling
argument for it (or for damage), so this is good info.

> (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.

Having been involved in MeeGo I'm painfully aware of the rapid
movement (ouch), where for us it's always seemed like only
next month's release will be new enough, sigh.

> (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.

tiff has been on this page for a while, but really
has no associated information, it's got an automatically
generated link to a wiki page, which is empty:

More information about the lsb-discuss mailing list