m.hearn at signal.qinetiq.com
Mon Aug 9 19:01:13 EEST 2004
> 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
> 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
> 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.
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.
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. :-)
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?
More information about the xdg