On Jan 4, 2012, at 11:43 AM, Jeffrey Johnson wrote: > Well "broken" is perhaps a bit harsh as a euphemism for > Not useful to you. > > ;-) included just in case; I don't believe we disagree here.
Chalk it down to perhaps a misunderstanding of the intended usage, but I'm not entirely certain on that point yet. :-) > The concept of mirrored markup used for depsolvers like yum/zypper/urpmi/smart > is what is "broken" imho. rpmrepo is/was intended as a client side, > not a server-side, tool. As a client side tool, the generated markup > is entirely intact, was known to work with (at least) smart at the > time rpmrepo was implemented, and the markup is still the same, > and would work with that version of smart, on the client no matter > what the createrepo de jure chooses to generate to feed to > yum/zypper/urpmi/smart. Alright, but two things: 1. Please explain the use case as a client side tool. I'm not sure I understand the intent there. 2. Regardless of _where_ the tool is used, what is the <open-checksum> supposed to be a hash of? It doesn't correspond to anything else I see in the generated repo, whereas the schema leads me to believe that it was intended to show the hash of the uncompressed file (as does the working functionality of createrepo) - if so, then it actually is broken. > I personally think (and I believe we agree) that a NoSQL! distributed store > instead > of mirrored content is more soundly engineered, mostly because its rather > easy to design an incremental update, which monolithic mounds of > spewage (as generated by createrepo and mirrored by rsync and downloaded > by url-grabber for use by yum) is still commonly doing. Yes, I'm still interested about the NoSQL solutions, but I'm a little hazy about the implementation details, how to get up and running with a mongo store (for this purpose). > Meanwhile, ROADMAP discussions for rpm-5_4 "features" are currently active at > http://launchpad.net/rpm > > Feel free to add to this "blueprint" > http://rpm5.org/community/rpm-devel/4444.html > and spell out the usage case (for others, not me: I already > know what I intended when I wrote rpmrepo). > > Adding bug reports detailing the "broken" and attaching to the "blueprint" > (I will do the attach if you don't wish to) so that the amount of effort > (and cost <-> benefit in general) can be estimated and scheduled/targeted > at some milestone is what is going on this month. > > Any/all additional information will only increase the likelihood of finishing > rpmrepo (or starting to use the embedded mongo-c-driver already present > in rpm-5.3). I'll try to see if I can spend a few cycles assisting with the above… JH ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
