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
