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.