<html><body> <tt>Mike Hearn <m.hearn@signal.qinetiq.com> wrote on 08/09/2004 04:25:29 AM: > Hi Bryce, > > Bryce Harrington wrote: > > Hi Mike, > > > > Regarding this issue of determining a "base platform" for desktop linux > > applications, is what you're looking for to be some sort of documented > > "desktop capabilities/requirements" list?  I ask because this is > > something we've been putting some thought into at OSDL with some of our > > desktop-oriented member companies, that could, for instance, specify the > > particular bits that software packagers could expect to be present > > across any distro/desktop. > > Yes, that's basically what I'm looking for. So far the LSB has not > addressed this issue but they seem keen, and maybe after C++ gets into > the spec it'll start to rev faster (sorry but a 2+ year release cycle is > far too slow for current desktop Linux development) and expand what's in > its base profile. If so then that'd be great.</tt> <tt>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@freedesktop.org gives them.    The LSB needs three things:</tt> <tt>1) stable libraries implemented by two or more Linux distributions</tt> <tt>2) detailed written specifications</tt> <tt>3) conformance test suites to validate that #1 are following #2 above</tt> <tt><a href="http://lsbbook.gforge.freestandards.org/new-abis.html">http://lsbbook.gforge.freestandards.org/new-abis.html</a></tt> <tt>A core desktop could be created quickly with the leverage of the proper amount of resources.  :-)</tt> <tt> > > The other concern I have about the LSB is that currently it seems most > distros don't actually install the LSB conformance packages. They are > very small and only add things like /etc/lsb-release, a symlink for the > linker and so on, but still distros like Fedora and SuSE don't seem to > include it in the base package sets. The LSB has been out for a long > time now, so this does worry me. How do you know if what you're > installing into is LSB compliant if the necessary files and symlinks > aren't in place?</tt> <tt>LSB Certified runtime environments should be providing an "lsb" dependency for LSB Certified applications to prerequisite.</tt> <tt> > > Last concern about the LSB I have is that I think it unlikely open > source desktop apps will ever actually be LSB conformant because they > will want to use libraries outside of whatever platform is specified and > the LSB specifically prohibits this. You might get a lot of informal > "mostly" compliant apps though.</tt> <tt>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.</tt> <tt> > > > Like you mention, LSB doesn't cover that particular level of detail. > > Does this sort of thing sound like something autopackage could make use > > of?  If so, maybe we could pick your brain about it a bit?</tt> <tt>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.</tt> <tt><a href="http://www.linuxbase.org/spec/book/Packaging/Packaging.html">http://www.linuxbase.org/spec/book/Packaging/Packaging.html</a></tt> <tt> > > Well, autopackage is only one piece of the "make software installation > on Linux easy" puzzle IMHO. It provides a way to distribute > dependency-checking/resolving packages that work on "any" Linux > distribution (obviously that's not really true, but it's Good Enough), > but there are still two things needed to make software installation and > development on Linux as easy as on Windows/MacOS: > > - A large, modern base package set. I say package set and not platform >    because I don't think there needs to be any API consistency rules (so, >    not like in KDE/Gnome for instance). Experience with Windows >    development leads me to think consistency isn't important. This is >    where organizations like the LSB, OSDL, freedesktop.org etc are >    needed, to define base sets that distros are actually going to install >    by default (or at very least, provide a single virtual package in >    their repositories to pull it all in).</tt> <tt>What should be available to an application is defined by the LSB Product Standards.   For example, there could be "server" and "workstation" product standards.</tt> <tt><a href="http://lsbbook.gforge.freestandards.org/spec-prod-std.html">http://lsbbook.gforge.freestandards.org/spec-prod-std.html</a></tt> <tt><a href="http://www.linuxbase.org/~taggart/module/20workgroups.png">http://www.linuxbase.org/~taggart/module/20workgroups.png</a></tt> <tt> > >    Large is I think important, perhaps the most important thing but also >    the most difficult to achieve politically(?). Win32 is large, almost >    unimaginably large. It is not consistent or frequently updated. > >    Nonetheless, in terms of supporting the development of advanced >    desktop apps without lots of static linking, it does >    very well.</tt> <tt>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.  :-)</tt> <tt><a href="http://www.linuxbase.org/futures/candidates/">http://www.linuxbase.org/futures/candidates/</a></tt> <tt> > >    This is needed to make installation robust/reliable (assuming >    developers have the discipline to stick to it). People will always >    use code outside the platform, this is necessary and healthy, which >    is why we still need dependency resolvers. But it should increase >    the installation success rate dramatically. > > > - Some kind of package management abstraction layer similar in goals >    (but not implementation) to the new HAL, ie something desktops >    can integrate with and depend upon. This would let us drive package >    management right into the heart of the desktop projects in a way that >    does not endanger their portability. > >    This is needed to make the whole process as slick and straightforward >    for end users as on competing operating systems. > > > Neither of those two things are in scope for autopackage. Obviously, > they all need to exist and work together for maximum effect so I'm > watching the progress of the LSB and freedesktop.org platform efforts > with interest, ditto for HAL. > > If OSDL feels it has something to contribute, please join the fray .... > > thanks -mike </tt></body></html>