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

Craig Scott audiofanatic at gmail.com
Mon Mar 7 15:37:12 PST 2011

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.

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

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

Also, would it be worth considering having the test results submitted to a CDash project instead of/in addition to the current test results page (see http://www.cdash.org/CDash/index.php?project=CMake for an example of how this might look). The ability to drill down to failures, notify site/host owners, see history of builds, etc. all seem to match fairly well with what LF need here. Not sure if it is feasible, but it does seem worth considering. The KitWare guys have been very responsive to recent submissions for getting CMake building with LSB compilers, so I wouldn't be surprised if they were willing to help get things set up. Potentially there could be a Google Summer of Code project lurking in here, but I don't know if there would be enough code development for it to be suitable.

On 08/03/2011, at 9:40 AM, Robert Schweikert wrote:

> On 01/12/2011 03:53 PM, Stew Benedict wrote:
>> Hi all,
>> I've cloned the wiki 4.1 Project plan page to 4.2 (if that's what we
>> call the next release) and have done some removals, adds, comments.
>> Please feel free to expand this document as a "laundry list" for us to
>> work towards a set of goals for the next release.
>> If you can't get write access to the wiki for some reason, email to the
>> list or myself and we'll try to get things added.
>> Any priorities on the current list aren't firm, many I changed to TBD.
>> https://www.linuxfoundation.org/en/ProjectPlan42
> OK, finally got around to add stuff.
> Also added items to the F2F agenda.
> Later,
> 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
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss

Craig Scott
Melbourne, Australia

More information about the lsb-discuss mailing list