On May 18, 2010, at 7:20 PM, Jeff Johnson wrote:
> On May 18, 2010, at 12:27 PM, Denid Washington wrote:
>
>    
>> Hi,
>>
>> You might remember me - I'm the one who wrote a sketchy implementation of the then-discussed "Berlin Packaging API" about two years ago [1]. I have shifted my focus to other things since then, but since recently have more time again and my interest on the topic has been sparked again.
>>
>>      
> Certainly I remember you.
>    

Great to hear. :)

>    
>> Now I am trying to gather what has happened since then. If I haven't missed anything, there was not that much to be missed. The packaging list archives seem to be effectively dead. The only thing I found was thoughts about uplifting to RPMv4 sprinkled around some LSB Wiki pages, for instance the LSB 4.1 Project Plan [2].
>>
>>      
> Yep. Nothing whatsoever to be missed. The last dialogue I was involved in was (~12/2008):
>
> 	Q: What is the _ONE_ most important item for the LSB 4+ packaging standard?
> 	A: Establishing a "standard" version comparison so that "newer" and "upgrade" are well defined.
>
> Nothing heard (by me) since.
>    

Unfortunate, but I thought as much.

>    
>> Now, because I remembered you, Jeff Johnson, to be very constructive, honest and generally helpful in criticizing my proposal (and always entertaining) and were very much involved in the whole discussion, I would like to ask you: what is the state of discussion regarding LSB packaging? Do you know about any progress on this front since, say, the end of 2008? Any hints would be very valuable for me, as I am seriously thinking about a second (maybe more coordinated, complete and consensus-reaching) attempt at working on a new LSB packaging proposal..
>>
>>      
> LSB packaging is as extinct as the Dodo AFAIK.
>
> (aside)
> You might want to look at http://mancoosi.org which is closest
> (but "research" not "standard", standards are much harder) to
> evolving something better for software packaging.

Will do so.
> There's also http://nixos.org which is attempting "functional" packaging
> that avoids many of the snarly issues presented by "standard" packaging.
>
> 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:

- Define the package API essentially as discussed before, with simple 
register/unregister methods, plus precisely defined package metadata.

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

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

There are probably a lot of issues with this path, but it might be a 
good start to experiment with. What do you think?

Regards,
Denis Washington