Will LSB 4 Standardize Linux? (InternetNews) [LWN.net]

Will LSB 4 Standardize Linux? (InternetNews)

Posted Aug 1, 2008 0:19 UTC (Fri) by derekp (guest, #53203)
In reply to: Will LSB 4 Standardize Linux? (InternetNews) by elanthis
Parent article: Will LSB 4 Standardize Linux? (InternetNews)

What the poster above was referring to is that if you develop your app on say RHEL, just
because RHEL is LSB compliant doesn't mean that your app won't accidentally rely on non-LSB
components also included in the base OS.  So your app may not work on other LSB-compliant
systems (because your app isn't a "pure" LSB app).

The solution to this is to set up a directory structure that contains _only_ LSB components,
then chroot into that directory and test your app.  If there are no problems, then it should
run on any other LSB-compliant OS.

(Log in to post comments)

Will LSB 4 Standardize Linux? (InternetNews)

Posted Aug 1, 2008 6:42 UTC (Fri) by k8to (subscriber, #15413) [Link]

I disagree, an ISV *could* do better.  They can say "we support the LSB4 platform".  And they
can investigate all bugs which come to light running on the LSB4 platform, and determine whose
side of the fence such problems are on and resolve them.

Some bugs will be on the distro side, and then it will be up to the distro to support the
platform.

Really it would be ideal if you could actually get both parties interested in such bugs.

You may be right that vendors will not go down this path, but there's no reason they can't do
so.  The issues you have to worry about are significantly curtailed if you target LSB.
However the catch is that LSB is a pretty limited platform, or was.  I haven't checked lately.

Better tooling and IDE support

Posted Aug 1, 2008 16:07 UTC (Fri) by salimma (subscriber, #34460) [Link]

This sounds like an integration problem: compared to, say, OS X development, where the Xcode
IDE let you target any of the last three OS X releases, Linux IDEs are not configured to
target any LSB versions.

Ideally, you should be able to deploy to a chroot-ed environment as part of the build process
too. There's still the library mess if your application depends on libraries that are not part
of the LSB standard, though..

Makes me think that adopting the Acorn RISC / OpenStep / OS X concept of application and
framework bundles would be a neat idea, as far as binary proprietary applications go: the
application is just a bundle (a directory), within which there is a predefined place for
bundling self-contained frameworks (libraries) that are in turn bundles themselves.

Application bundles? Puhlease.

Posted Aug 1, 2008 17:46 UTC (Fri) by khim (subscriber, #9252) [Link]

If you ever worked with these "magic" bundles you'll know they work just fine if we are talking about small self-contained applications (like Firefox or Skype) - exactly where trivial solution (.tar.lzma) already exist - but easily break apart if we are starting to talk about big integrated packages like MS Office/Acrobat (not reader). Then you have the whole non-standard scripts, arcane installation commands and so on.

Sorry. This is non-solution for non-problem. 0install is slightly better - but not by much: basically it's huge distribution without any control with ability to run software from thousand of repositories.

All existing systems are totally, utterly useless because they are addressing easiest 90% of the problem while leaving really problematic 10% untouched. Result: complex system which offers no significant additional value over simple tarball.

Application bundles? Puhlease.

Posted Aug 2, 2008 20:18 UTC (Sat) by salimma (subscriber, #34460) [Link]

The advantage of bundles is that it contains more metadata than a simple tarball.
Compatibility problems might arise, but at least the application launcher could provide more
meaningful feedback to the user.

Or even integrate with the OS' version control system, especially now that Linux has
PackageKit, to say "hey, the user wants to run this new bundle that needs libfoo-x.y, install
whatever package is necessary to provide that".

You'd need a package management system that automatically scans built packages for what
libraries they provide; RPM does that, not sure whether DPKG does.

Application bundles? Puhlease.

Posted Aug 2, 2008 20:51 UTC (Sat) by salimma (subscriber, #34460) [Link]

I elaborated the point on my blog. To summarize, a bundle allows for better integration with the native package management system. It provides a more user-friendly experience too -- drag and drop your applications and libraries. I forgot to argue that in the blog entry.

And who can use this metadata?

Posted Aug 3, 2008 13:20 UTC (Sun) by khim (subscriber, #9252) [Link]

The advantage of bundles is that it contains more metadata than a simple tarball.

So what? README.txt/INSTALL.txt written in English is quite good for human and it's impossible to use metadata till there are no organization which resolves conflicts, give canonical names for libraries, etc. It's easy to request "convert" binary - but then your application will fail due to difference between ImageMagick and GraphicMagick flags. It's easy to request QT 3.3.x but then your application can not start since ABI was changed when immodule-qt was used. And if you need to just start your own background service - you still need to supply bunch of scripts for different distributions. Libraries and binaries (which is currect focus of all these systems) are easy, almost trivial: HDD space is cheap so just bundle all libraries with your package. Easily doable with tarball. And the hard stuff (do you need to talk with esd? with arts? or use PulseAudio daemon?) is not solved by current generation of bundle systems.

Note: I've not said that bundles can never ever work. Who knows? Perhaps sometime in the future... when all will ditch this obsolete Linux and switch to great new HURD... but not today. So far all tries failed miserably. They are either work for limited usecases (0install is example here) or threaten to kill the host system altogether (autopackage and friends).