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