The LSB Package API is an recently suggested interface that allows ISVs to install LSB-compliant applications in such a way that they are integrated into the distribution’s packaging system.
This enables users to manage third-party software packages as easily as packages installed from the distributor, and frees ISVs from the need to provide packages for different packaging systems in order to achieve integration with the distribution.
This is meant to be a low level library with minimal dependencies that can be used by ISV’s.
Summary:
Uses a DBUS service: check
Uses pluggable backends: check
Use PolicyKit: check
Use an XML parser: check
System activation: check
Define own linked list implementation: check
Try to solve a problem that doesn’t exist: check
This “give packaging power to users thing” has been tried before a few times before and fallen on it’s face each time. There’s a reason that PackageKit uses the distro supplied packages, rather than trying to define it’s own package and metadata format.
I’ve spent nearly a year developing PackageKit on many distros, talking to customers and software vendors and I’m really struggling to see the viability of a LSB Package API. So few people care about the LSB, and the vendors that do, don’t want to be using a PolicyKit enabled dbus-activated service just so an admin can copy files to a disk.
If there was a requirement for a distro-neutral 3rd party application installer (which I don’t think there actually is) then it should be a tiny shared (static?) library that just depends on libc or /bin/sh.
PolicyKit, DBUS, XML should all be left waaaay higher in the stack, something like, cough, PackageKit… I’m afraid the LSB Package API has got caught in the classic new project trap of “wouldn’t it be cool if we used ${technology}” and actually forgotten to ask customers what they want. I just think the committee has lost the plot a little on this one.
LSB Package API: FAIL.
“If there was a requirement for a distro-neutral 3rd party application installer (which I don’t think there actually is) then it should be a tiny shared (static?) library that just depends on libc or /bin/sh.”
such as autopackage? The dutch IRS use it to distribute their linux version of the tax form submission tool. It’s useful for those kind of situations (one package for all distro’s, you don’t care about updates, you don’t have much dependencies, you want to distribute binaries)
@jauco:
Exactly like autopackage. Klik and autopackage both fill this need quite nicely and are established bits of software. Installing stuff like this per-system is just a world of pain.
“If there was a requirement for a distro-neutral 3rd party application installer (which I don’t think there actually is)”
You are _so_ wrong there it’s not even funny. The current linux state of affairs so so bad, that we (abiword developers) have stopped making linux binaries alltogether.
@uwog:
Why do you need binaries? Is there a distro that doesn’t support abiword? If it’s just for testing unstable versions, surely autopackage is what you want to use?
Note: I neither claim nor believe that the packaging API mentioned is the solution; I am merely arguing against the statement that third-party software support is unnecessary.
The distribution-centric packaging setup on Linux is its sole major wart left in the “Linux at Home” movement. It is KILLING Linux usability. There are several very clear reasons:
1) Distros do not, and never will, package EVERYTHING.
2) Distros do not supply updates to packages as soon as upstream releases new versions (and often never supplies updates), even when those updates are safe (no new bugs) and/or critical (look how long it took to get FIrefox3 pushed to Fedora9, despite the usability-slaughtering performance problems with the beta5 that Fedora9 shipped).
3) There is a huge category of proprietary applications that almost every single real home user** is interested in: games. The few Linux native games that have come out are an absolute bitch to install, and in several instances, were impossible to install without deep voodoo knowledge of Linux, X, shell script, and vairous other parts of the GNU stack.
** Linux users — even those who use Linux as their desktop at home — completely fail to represent the common home user. We use our computers solely for the sake of using them, while the rest of humanity uses them to get something done or to run specific applications. Look at it like this: some people love pulling apart cars, fixing them up, customizing them, and diagnosing problems. Most of us would get rid of a car faster than you can say “lemon law” if it required us to work on it that much, because we just want to get in and drive and not have to spend half our waking hours tinkering with the damn thing.
Most Linux users simply fail to realize the importance of games. It’s pretty obvious why that is: we don’t (generally _can’t_) play them, and so we either represent the minority that isn’t interested in games or the minority that willingly gives them up. I cannot name a single person – not one friend, family member, co-workers, or acquaintance – who does not have at least one proprietary game that they love greatly and would not do without. It’s bad enough we have to resort to Wine to play many of those games, but it’s even worse when it’s __easier to install a Windows-native game in Wine than it is to install a Linux-native game__. Install Warcraft3? Stick in the CD, double-click the install icon, done. Install Linux-native NWN? Stick in the CD, double-click the install script, watch nothing happen… open a terminal, run the script manually, get weird errors about X utilities missing… copy the script, make use of deep voodoo knowledge to fix the script, and finally get it to run and install. Seriously, this is a problem.
Games also suffer from a serious issue in terms of reimplementing as Open Source that no other software suffers from. Nobody really gives a shit which word process they use, so long as it does everything they want and can open the files people send them. But people DO care greatly about which specific games they are playing. Even if some group finally (and this has yet to even come close to happening) created a top-notch 60+ hour RPG with engaging game play and a wonderful story, it would not be NWN. It might be a fun game, but some people will very specifically want NWN because it has its own unique story, art, and so on that is (justly and rightfully) illegal to duplicate due to copyright. Individual games have unique plots, characters, or other elements that make that specific game attractive, so just creating another game isn’t an option. You could make the best FPS game around, but I can guarantee my father would still want to (also) play the next Unreal game because he likes the story and his familiar with all the prior titles.
There’s also the simple matter of game data: even if NWN were fully Open Sourced, content and all, Fedora or Ubuntu or whatever will NEVER ship the 3+ GB of game data NWN includes. Or the 2+ GB that Unreal 3 uses, or the thousands and thousands of GB of data that would be needed to include the data for the sum of all popular games on the market. If we want to hope that Open Source can someday create an excellent game up to modern standards in terms of length, content, and visual appeal, we have to offer a way for those games to be installed outside of the Linux distro model. We have to make them easily installable so I don’t have to manually install external installation utilities or run shell scripts (like Autopackage), deal with hoky and unintegrated solutions (like LokiSetup or its descendents), or requiring vendors to include that same 3+ GB in ten different formats for every freaking variation of every distro out there.
We NEED a way to install software from a CD or from a web site that doesn’t require explicit conformance with a specific version of a specific distribution, or we will never, ever be able to offer a compelling home desktop outside of the small niche of Linux loyalists or specific corporate environments.
> The current linux state of affairs so so bad, that we (abiword developers) have stopped making linux binaries alltogether.
Good.
Although, not strictly accurate — you’re just not putting them on your web page:
http://fedoraproject.org/wiki/Interviews/AbiWord
> We try to get as close to the distros as possible. For example I’m the AbiWord maintainer in Fedora. That really helps us to get high quality packages in the distribution.
> Another good thing is that Fedora is really close to upstream. I often push an Abiword update to Fedora even before it hits abisource.com, which is very nice to be able to do.
> The lack of bureaucracy is a real blessing.
I think more people should emulate the great work you’re doing distributing abiword to fedora users, so we can forget about random packages on web pages. Thanks!
I do totally agree Sean Middleditch.
As he says distros will never package *everything*; installing from repositories often requires internet connection.
Linux needs an equivalent of “.msi” or “setup.exe”.
@Sean Middleditch, i never agreed with a response as yours, man you need to have a blog somewhere.
@ diego, amen my friend
@Sean: Amen brother!
Let me just add that this is actually, and sadly, why Wine is the most important project ever and if one project should have all the resources (to fix bug #1 or whatever reason), Wine is it: not because of future games, which should (at some point) start to come out for Linux native. We all want that to happen, and hope it will.
It’s for all those thousands, millions of games that are already out there, will never be ported and actually are important enough to keep Windows around for many of us. These games are many, oh so very many.
This is for the same reason why MAME, ScummVM and all the other game system emulators are so popular – Windows games are not programs other than in the most technical respect. They are actually documents locked in a proprietary format – the Win32 API with DirectX and what have you. Treating games just like any other application is a fallacy at best. If you create a really good Gimp or Krita, you have a replacement for Photoshop – bitmap manipulation solved. OpenOffice can take on MS Office – documents solved.
But if you create one good Counterstrike clone, you might have replaced Counterstrike. And chances are, you haven’t.
/offtopic rant done, for this time. It just fit in with how enormously important games are for a huge part of the computer using community, and it’s only getting bigger.
klik2 only works by bundling dependecies. This means that you need to have a old linux distro around if you want to support users who are not upgrading like crazy.
Fact is: it is not easy to support a variety of Linux distros by a simple package. It never will be.
AFAIK, PolicyKit, DBus and libxml are now default components of any Linux system. Why not use it?
Do you prefer reinventing the wheel yet again?
There’s cleary a need for an _universal_ third party application package format for Linux systems.
Right now, if you’re an ISV and want to target Linux systems (not even 1.5% of the market) you will want to make (at least) packages for Enterprise distros, SLED/SLES/RHEL and for the most popular community distros: Ubuntu, openSUSE and Fedora.
It’s cleary easy to see why Linux is failing on the desktop…
Right now, distros are pretty much reduced to packaging every applications out there (a noble but impossible goal) instead of being able to innovate where it matters: integration.
Hi, I am the one who proposed the LSB Package API (hmm, I guess I might need some name that doesn’t make it sound as official..). First of all, for those interested, I recommend you to take a look at the pages linked to at the proposal page (which Richard has already linked to), they have some important background which comes a bit short on this post.
Now, to the blog post itself.
“This “give packaging power to users thing” has been tried before a few times before and fallen on it’s face each time. There’s a reason that PackageKit uses the distro supplied packages, rather than trying to define it’s own package and metadata format.”
I don’t believe that this is a reason to not try again. In fact, when I learned about PackageKit, I was actually a bit disappointed about that fact that it just provides an interface for the already-existing software management facilities (apt etc) and didn’t try to get to the (IMHO) “real” problem: third-party software installation. Even if there were some failures when attempting to fix the situation, I really believe it can be done, and we should try our best to get it done, not resignate before even getting started.
About the just-the-coolest-tech argument: I didn’t choose D-Bus and PolicyKit because they are the latest and greatest – I chose them because they just do what I need. D-Bus allows the definition of an language-neutral API, and PolicyKit is just great to implement the least-privilege principle, which is crucial for installing third-party software (the installer should just be able to do what it needs to do, not run as root). None of these technologies are used for the sake of using them.
Note that, while the system daemon uses all these technologies, installers using the API would only have to use a small C library with a small handful of functions. So most of the architecture is abstracted away.
@hugsie: for a start because distributions fsckup often (anyone remember Ubuntu not shipping ODT support for AbiWord by default?).
Also because we want to be able to provide users with the latest version of AbiWord (anyone remember ubuntu refusing to include AbiWord 2.6 in the last release, even through we provided all the work (the .debs)?).
We tried autopackage. It’s a nightmare to maintain and have working on all systems. That’s why we dropped it for 2.6.
> I’m afraid the LSB Package API has got caught in the classic new project trap of “wouldn’t it be cool if we used ${technology}” and actually forgotten to ask customers what they want
Don’t want to sound harsh, but I’m afraid that it’s you that forgot to ask what customers want. Compare these:
http://www.skype.org/intl/en/download/skype/windows/
http://www.skype.org/intl/en/download/skype/macosx/
http://www.skype.org/intl/en/download/skype/linux/
Click on the “Download now” button and imagine how easily fresh users of Windows, Mac and, say, Fedora Core 9 would install Skype. Windows and Mac guys won’t need to know what versions of Windows or OS X they own (as long as the system meets the minimum requirements). Linux users are out of luck. Do you have Fedora 9? Oops, there are only 6 and 7. Maybe the version for 7 will do. Or then again maybe not. Is Ubuntu 7+ ok for Kubuntu 8.04? Average user doesn’t know and *doesn’t have* to know these things. On other system they click and go, on Linux they have to either hope that someone put a recent version on the repositories or they’re scre*ed…
If things don’t change, no matter how shiny Linux GUIs may become, or how powerful the whole system may be, average users will be cut off. You have to be a geek or have someone to babysit you in everything more advanced than turning the machine on and off… and this doesn’t help Linux adoption at all.
My two cents…
A large part of the problem is that a lot of people don’t recognize it as a problem. It was so back in 2004 when Autopackage started, and it still is. The fact that there is a technical problem right now is because of politics.
Sean Middleditch, Athrun and Denis Washington are spot-on. It still surprises me why, despite these stories, there are still people who don’t recognize the problem.
Denis names as ‘the “real” problem: third-party software installation.’
I agree.
But this wording may easily be mis-understood. What will come to mind to most people as their first and only idea when reading this: “ah, he speaks of ISVs, who want to sell their proprietary stuff, make their profits and not contribute anything to FOSS”.
While these proprietary ISVs are part of the “third parties”, to me they are not the most important ones.
If I use openSUSE, and want to use the “scli” (SNMP Command Line Interface: there is no SUSE-RPM available! But there are .debs. Now you let me install that .deb on my openSUSE via a $whatever API and $foobar KIT, and you helped me making install a “third party software” on my openSUSE.
If I use Fedora 8, and want to use “kinternet” (a useful KDE-based frontend to PPP-dialup connections, helping me to establish UMTS links when I’m “on the road”): there is no Fedora 8 package available! But there are openSUSE RPMs. Now you let me install that openSUSE RPM on my Fedora via a $whatever API and/or $foobar KIT, and you helped me make install a “third party software” on my Fedora.
Got the idea now?
Sorry. I am a rookie. And I want only one package! ;-)
My mother knows what is Fedora, Ubuntu…