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".
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.
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.
> - Define the package API essentially as discussed before, with simple
> register/unregister methods, plus precisely defined package metadata.
>
Nothing wrong with register/unregister methods.
And "precisely defined" is on the right track, register/unregister certainly
need markup spewage that is parseable, or other gozzintas/comesoutas.
(aside)
Look carefully at CUDF from http://mancoosi.org. There are some flaws, like
Version: is typed as an INT (versions in the real world are far more
complicated),
but everything else is quite carefully defined, including "package" and
"upgrade".
> - 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.
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.
> - 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.
> 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.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
LSB Communication List rpm-lsb@rpm5.org
