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
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
