gnome-hello

[Mike Hearn]

> The LSB is wanting an absolute API/ABI.  The LSB does not want to step 
> on any toes, and the desire is for standards to be sanctioned by the 
> upstream maintainers; therefore, the LSB will import what 
> xdg at freedesktop.org gives them.    The LSB needs three things:
> 
> 1) stable libraries implemented by two or more Linux distributions
> 2) detailed written specifications
> 3) conformance test suites to validate that #1 are following #2 above
> 
> http://lsbbook.gforge.freestandards.org/new-abis.html
> 
> A core desktop could be created quickly with the leverage of the proper 
> amount of resources.  :-)

I don't think even GTK+ at this point would pass those criteria: unless 
you do s/detailed written specification/documentation/ how are you going 
to specify the behaviour of something as complex as a widget toolkit? 
Remember parts of the GTK documentation aren't complete!

What about bindings - PyGTK is a great RAD tool that quite a few apps 
depend on these days, but a Python ABI is a very different thing to a 
C++ ABI: arguably, there is no such thing, and the API == ABI in the 
case of languages like that.

> LSB Certified runtime environments should be providing an "lsb" 
> dependency for LSB Certified applications to prerequisite.

I'm sure they do, but unless it's installed out of the box it's hard for 
ISV installers to check the LSB compliance of a program. Stopping and 
saying "please install the LSB package for your distribution" isn't an 
option for retail desktop developers I'm afraid, not when it can be done 
without that.

> Mostly compliant is the short term.   Specifying the desktop application 
> universe for ISVs is the long term.  Bleeding edge open source desktop 
> applications will continue to be built from source so they can use the 
> latest bells and whistles.

I don't think that makes sense, the "bleeding edge"-ness of an app 
shouldn't affect how users install it (I assume that's what you're 
talking about, seeing as all software is built from source at some point :)

I'm under the impression that we are using different definitions of 
"ISV". You are meaning (typically) very large companies who make 
expensive pieces of software and so ease of installation is not a big 
factor for them. Once you bought the software, installing an LSB 
conformance package is no big deal. A much bigger deal is having a 100% 
watertight guarantee that it'll run.

When I say ISV, I am thinking of:

- Open source developers, possibly individuals
- Small proprietary/commercial vendors like Icculus (game ports),
   CodeWeavers (Wine variant), VMware, Skyper and so on.

For these groups, ease of installation and use on very modern systems is 
absolutely critical and having detailed written specifications is less 
important than being able to depend on a variety of modern components 
(so they can be competitive and well integrated).

Basically I'm not convinced you can have both very detailed written 
specs like what the LSB does, and a very large and rapidly revved 
package set. At least, not without really huge quantities of manpower.

> Could the autopackage project and the distros define what should be 
> specified in the next major release of the LSB?    We attempted an 
> FSG/LSB packaging group about three or four times, but resources/time 
> never materialized.   I will try to recover the webpages.
> 
> http://www.linuxbase.org/spec/book/Packaging/Packaging.html

autopackage isn't really relevant here. It's just a useful tool for some 
kinds of ISVs (open source developers, primarily). For these sort of 
platform discussions, the community both of developers and distributions 
is where it's at.

For the record, I was involved in one of those packaging attempts. We 
tried to agree on shared package naming and metadata conventions, iirc, 
but there was far too little interest from distro vendors to make it fly 
(well, Red Hats JBJ was pretty good, but other distro representatives 
didn't have enough time/motivation). I don't think that's relevant here 
either, it was a totally different goal.

> What should be available to an application is defined by the LSB Product 
> Standards.   For example, there could be "server" and "workstation" 
> product standards.
> 
> http://lsbbook.gforge.freestandards.org/spec-prod-std.html
> 
> http://www.linuxbase.org/~taggart/module/20workgroups.png

Sure, a workstation standard with perhaps laxer requirements than a 
server standard would be great.

> If you dont have an absolute ABI specification, then one must bundle 
> shared library dependencies with your application or statically link.   
> If one wants to reduce this, then its just a matter of resources applied 
> to the LSB to increase the scope.  :-)
> 
> http://www.linuxbase.org/futures/candidates/

Well, the reason companies like Microsoft and Apple can get away without 
these sorts of specs is because the software itself defines the ABI. I 
understand that you wish to allow the ability to fork, substitute 
implementations and so on, but I don't see why this leads to "must 
precisely document the ABI".

If you want to fork or reimplement a library while maintaining 
compatibility then the binaries/source of the original library is the 
standard you are working to - as experience from Wine shows, even things 
like what bugs are in the original library can be very important. I 
really doubt the LSB specifies what bugs shine through the interface, right?

thanks -mike