Hi, First of all, your nicest post so far. Thanks. ;)
On Sun, 2008-06-22 at 11:25 -0400, Jeff Johnson wrote: > 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. I hoped I could get around the language choice using D-Bus actually. But as there is just a convienience library for C currently, that's still a problem, somehow. > 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. Thanks. > 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. That would be great. Although there a some things that aren't there on purpose currently. One example is file permissions; an installer should be able to adjust its installed files as it wishes and let ClosePackage() gather the permission information. Such things could also be in the package manifest files though if this is better. > (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. Great. I guess the whole "trust" and security issue will need to be discussed thoroughly in the near future. > 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. Makes sense. > 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. Sounds like a good plan, yeah. I'm glad being able to work with you on this, as you certainly have a LOT more experience than me concerning this. Thank you very much! Regards, Denis ______________________________________________________________________ RPM Package Manager http://rpm5.org LSB Communication List rpm-lsb@rpm5.org
