RPM Community Forums

Mailing List Message of <rpm-lsb>

Re: The state of LSB Packaging?

From: Denis Washington <dwashington@gmx.net>
Date: Wed 19 May 2010 - 20:26:47 CEST
Message-ID: <4BF42D67.4000208@gmx.net>
Am 19.05.2010 19:24, schrieb Jeff Johnson:
> On May 19, 2010, at 5:57 AM, Denid Washington wrote:
>
>    
>>> I'm still willing to help however I can with LSB+RPM. Its _INSANE_ to continue
>>> futile "Packaging War" battles and and no users benefit (but certainly
>>> distros/vendors benefit from de facto monopolies through customer
>>> lock-in using software packaging).
>>>
>>>        
>> Good to know, I would be thankful for any kind of help. Right now I am thinking hard about how an LSB packaging standard would have to look like. I still like the idea of a package-manager-agnostic packaging API, but I came to believe that a standard would have to be something that is actually implemented in current LSB-certified "enterprise" distros - I underestimated how unwilling the LSB seems to be to lead instead of just following. So for any packaging standard to come, it is clear that it must work without any distro-side modifications.
>>
>> The question is how this requirement meshes with the package API idea. Currently, I am thinking of the following:
>>
>>      
> The logic flaw here is attempting a method based API approach.
>
> If you want an "API", you have two choices:
> 	1) Write your own API.
> 	2) Trick someone else into writing your API.
>
> LSB was very much about 2) not 1) and they failed to trick anyone.
>
> (aside)
> What should be done first is to get workable concepts for fundamentals
> like "package" and "upgrade". Sure you can start with simple abstractions like
>
> 	A "package" has a "name" and a "version" concatenated in a string.
>
> but there's a whole lot more that needs to be done in the "real world".
>    

I know. As I stated, the metadata needs to be defined as precisely as 
possible. As I am only roughly sketching a rough plan how to proceed, I 
haven't got into the details yet, but yes, that is the single most 
important thing that a future LSB packaging standard must specify.

> Note that the fundamental flaw with "LSB packages" and the "LSB package format"
> is that LSB hoped to piggy back on a de facto existing implementation called RPM.
> LSB has _NEVER_ attempted anything but attempting to ram home a "standard" for
> RPM packaging. And again, they've failed to "trick" anyone with the "LSB packaging standard".
> There are in fact no LSB "standard" packages because the "standard" describes
> a "LSB format" that is no longer widely used by any RPM implementation.
>    

I realize that.

> What follow are some suggestions. I'll assume that you will eventually
> figger well defined meanings for "package" and "upgrade" and other absolutely
> essential data items.
>    

So do I.

<snip>
>> - Design an implementation with backends for different package systems as started before, but with the difference that the implementation does _not_ need to be installed on the distro, but can be linked into an ISV's installer. In the case of RPM, this could be done with librpm. (Probably the pre-4.6 "legacy" RPMv4 API, as that should be what all RPM-based LSB distros support.) For other package managers like dpkg, which don't have a public library, packages would have to be created on-the-fly and installed, much like some installers currently do as well (the ATI binary driver installer comes to mind).
>>
>>      
> If you want different backends, you end-up getting into implementations and APIS where
> you need to "trick" up implementations in order to proceed. See how LSB failed, and
> don't make the same mistake.
>    

The whole backend architecture is explicitly thought as an intermediate 
solution. Distributions are encouraged to implement that interface 
cleanly in their package managers, thus avoiding any "tricks" / hacks. 
But for the API to work *now*, we need a fallback implementation that 
can be shipped with installers and does the job on today's distros, even 
if maybe somewhat hacky.

That said, the approach *is* problematic. But I fear that, if the 
proposal won't work on the current LSB-certified distros, it will be 
turned down real fast. And, the fallback implementation would naturally 
use the "clean native" implementation of the system's package manager if 
it is enable, so the fallback solution will only be used on "legacy" 
distributions.

> Meanwhile, what you are describing (and guessing from your previous freedesktop-like
> implementation), you might as well just use PackageKit, which already has backends
> and more.
>    

Interesting how often my proposal was directly compared to PackageKit 
(including PackageKit author Richard Hughes himself) just because of the 
choice of technologies.

PackageKit is designed as an interface for installing distro-specific 
packages or getting specific packages from distro-specific package 
repositories. That's its use case. Registring software in the package 
manager's database that does *not* come in the form of a native distro 
package is completely outside of that use case. Adding that to 
PackageKit would not make much sense imho. Also, PackageKit is not used 
in many distros (only in RHEL probably) so it is by far not a candidate 
for inclusion into the LSB.

Also, I am aiming for a more low-tech implementation this time. As the 
fallback implementation must work without being installed on the system, 
things like registered D-BUS services and PolicyKit are a no-no anyway. 
A simple library depending only on libc (and glib, if I'm lazy, plus the 
package-manager-specific libraries used in the backends) will most 
probably do, assuming the installer will run as root (which is no worse 
than existing ISV installers).

>> - In parallel, fill the holes in the LSB RPM spec (possibly uplifting to v4) and try to synchronize the metadata semantics with the ones of the package API (meaning, probably, that the package API will end up receiving RPM semantics at many places). This means we will have the package API for things like cross-platform installers on the one side and the RPM format as an alternative direct format on the other side, and we may be able to keep compatibility with the old RPM spec. (Crucial as the LSB 4.x series is committed to backwards compatibility.)
>>
>>      
> Please, its the "LSB format" spec, not the "LSB RPM spec".
>
> The distinction is crucially important.
>
> What LSB has chosen to make "standard" has nothing to do with RPM for
> many years now.
>
>    

As you please.

>> There are probably a lot of issues with this path, but it might be a good start to experiment with. What do you think?
>>
>>      
> For register/unregister (and "transactionally protected" ACID behavior), I'm
> currently embedding sqlite3 in RPM, and using sqlite3 "virtual tables" (VT) as
> an abstraction for register/unregister (largely because sqlite3 VT have two
> phase commit methods), and using SQL as a data focussed implementation language.
>
> Note "data focussed" and de facto bog-standard as the basis for choosing SQL.
> I don't particularly like SQL or sqlite3 implementation languages.
>    

Unfortunately I don't understand what exactly you are trying to do. 
Could you elaborate a bit on this?

Regards,
Denis
Received on Wed May 19 20:27:10 2010
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.