[lsb-discuss] LSB conf call notes for 2008-02-13
ddavis at novell.com
Wed Feb 13 13:02:06 PST 2008
Jeff Licquia wrote:
> Attendees: Jeff, Stew, George Kraft, Sam, Jesper, Mats, Darrin Davis,
> Robert Schweikert, Carlos Duclos, Marvin, Alexey, Kay, Russ Herrold
> Carlos: F2F? Jeff: at Collaboration Summit, week of April 7. Actual
> Summit starts Tuesday, LSB-specific stuff starts Thursday, extends
> past the LF Summit to Friday and Saturday. Mats: Ted's email to the
> list has the info.
> Java. Jeff: Kay: the people who own the Java runtimes should be
> creating the LSB-compliant JDK. Robert: agree, the LSB should provide
> what the JRE needs in 4.0, and the JRE owners should then certify.
> Darrin: certifying class paths? Want Java apps to drop on LSB system
> and it have a good chance of running. Robert: should distros install
> a LSB-certified Java runtime? Can we get a LSB JRE certified by the
> 4.0 release? Kay: working on Java 6 JRE runtime. What does it mean
> to make it trial use? Jeff: start gathering data on the status of
> JREs in the distros. Kay: would a trial use standard help to boost
> need for LSB certification of the JRE? George: yes. Kay: specifying
> where jars get installed is an important part. Robert: for 4.0, get
> JRE-required symbols, get JRE vendors to certify, standard class path
> in trial use. Darrin: JPackage allows multiple JREs; maybe the LSB
> should do that too. George: how does JPackage handle multiple JVMs?
> Darrin: will research and send to the list. Jeff: is there a standard
> class path already? Darrin: JPackage covers this as well.
OK, pretty straight forward. First to deal with the multiple JVMs, we
just use the Debian update-alternatives system. Talked about here;
I also found another implementation here;
The Linux/Debian Alternatives system is talked about with JPackage, but
JPackage doesn't implement that. It's goals are pretty straightforward
from their website http://jpackage.org/
> The JPackage Project has two primary goals:
> To provide a coherent set of Java software packages for Linux,
> satisfying all quality requirements of other applications.
> To establish an efficient and robust policy for Java software
> packaging and installation.
> We focus on free and open source software whenever possible. For
> convenience, we also provide non-free packages without the restricted
> source code.
So, I recommend from the JPackage project that we investigate the
> New library list in ProjectPlan40. Robert: libresolv no, Python C
> bindings is part of "future of Python" question, probably unrealistic
> to specify more of Perl or Python in 4.0. Yes to GLU and some X
> extensions, Xmu, Xpm.
> Robert: not Motif. Motif can be shipped; make sure it can be shipped
> if needed. Kay: only seen 1 Motif app.
> Carlos: might be complicated to require SSL because of country and
> export regulations. Robert: may not be a candidate for 4.0 because of
> legal, tech issues. Mats: libcrypto is #1 in demand, libssl is #5.
> Robert: LF lawyers may need to take a look.
> George: on Motif, also compatibility issues with lesstif. Some people
> still shipping Motif binaries.
> Jeff: SSL should continue to be researched. Robert: maybe talk about
> at the F2F in April.
> Jeff: Cairo is pulled in by newer GTK+, shouldn't be controversial.
> Upstream seems enthusiastic.
> Carlos: Qt uplift? Jeff: on uplifts page, will be considered, most
> likely a resource issue. Carlos: can provide resources.
> Mats: "better C++ support". libsigc, C++ bindings. Robert: should be
> prominent, compatibility issue still a problem. Jeff: improvement?
> Robert: definitely, but the deprecation policies are still an issue.
> If compatibility issues are under control, then more C++ stuff is
> probably good. Jeff: combinatorial problem with bindings; should wait
> for demand before adding bindings. Robert: need a way for ISVs to
> register demand; should do in 4.0 timeframe.
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
More information about the lsb-discuss