On Jun 21, 2008, at 12:48 PM, Denis Washington wrote:


My current interest in your code is disaster prevention, not
otherwise.

I welcome any motive if it improves code quality, so thanks anyway. ;)


NP. My life is hell when rpmdb's get hosed up. Doesn't matter whether
its a kernel mmap(2) flaw, an selinux policy-of-the-day typo, or a
python
script kiddies dain bramage.

The "Berlin API" is a recipe for disaster so far.

But I'm most definitely deeply and personally interested in not
having to do the necessary rpmdb maintenance post-mortem
if the implementation problems can be solved.

Thought so.


Hehe, now that your ideas have been thoroughly shredded ...

Here's what is right about the Berlin API, and your approach:

0) A means to register/unregister a "container" (I'm avoiding the abused term "package") of content on linux systems that is more lightweight and more flexible
than existing containers like rpm/dpkg needs to be devised.

1) The "Berlin API" -- for all its flaws -- is a reasonable step towards the
goal of registering/unregistering content on Linux systems. The largest
flaw with the "Berlin API" LSB proposal imho was stating the problem as
API methods without specifying the "container" internals, and how the internals should be represented and used. Implementing an API also involves practical
development choices, like what language to use, that are incidental to
the goal or registering/unregistering content.

2) Your implementation of the "Berlin API" got lots of things right. First of all, the API itself in your implementation is in Yet Another Library, which avoids he hugely complicated problem of how to retrofit an API onto already released software. Second, your implementation exists, a necessary precursor to identifying
what else needs to be done. Making an implementation of the "Berlin API"
exist in some meaningful form is more than anyone at LSB or on the packaging has achieved in ~1.5 years. Using dbus, and splitting the API from back-end
processors using a domain-specific markup, are also sound architectural
choices imho.

So Congratulations! are most definitely in order.

If you want to proceed, I'll be happy to write the RPM back-end for you.

Its easier for me to just build a Header that I know will Just Work (tm) when
passed to rpmdbAdd() than it is to explain to you what needs to be done.
So far, your "Berlin API" implementation is sufficiently complete that
I can see that a well-formed Header can be achieved. OTOH, you
will have to supply the necessary data elements to add to the header,
I can give you a list if you wish to proceed.

(aside) Note that I'm quite capable of generating digital signatures on the generated header from the "Berlin API" any time that the "trust" discussions get out of hand.

I can also likely help generate the XML (or YAML or klik or 0install or
repo-md or ...) markup that is going to be needed to express the
"container" contents. I'm actively generating markup of various persuasions from Header content @rpm5.org already. One more (or less) markup implementation
simply doesn't matter, just try to get the markups prioritized please.

What does matter is that all the widdle markups interconvert easily, and
are sufficiently rich in expressive power that common elements, like
file stat(2) data, or ACL's or xattr's or ... can be represented (and converted) without hugely complicated political packaging war battles that are ultimately
about cellophane "container" wrappers.

Sound like a plan? My primary goals here are two-fold:

1) avoiding disasters if bogus headers start to be added to an rpmdb.

2) exposing rpmdbAdd() (and rpmdbRemove()) methods for use by
LSB/ISV/whatever applications that wish to register/unregister software
on RPM managed systems.

73 de Jeff
______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
LSB Communication List                                rpm-lsb@rpm5.org

Reply via email to