Better tooling and IDE support [LWN.net]

Better tooling and IDE support

Posted Aug 1, 2008 16:07 UTC (Fri) by salimma (subscriber, #34460)
In reply to: Will LSB 4 Standardize Linux? (InternetNews) by derekp
Parent article: Will LSB 4 Standardize Linux? (InternetNews)

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.

(Log in to post comments)

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).