On Jan 4, 2012, at 9:52 AM, Jeremy Huntwork wrote:
> On Aug 30, 2010, at 8:48 PM, Jeremy Huntwork wrote:
>> Hello,
>>
>> The concept of rpmrepo really appeals to me. It seems like the 'Right' way
>> to generate repo metadata. What better place to compute and discover rpm
>> data than within the rpm package itself?
>>
>> Having said that, in playing with rpmrepo, I've hit a few bumps. The current
>> one appears to be incorrect computation of sha1sums for the <open-checksum>
>> tags on files.
>>
>
> [snip]
>
>> Note that the sha1sum above does not match the <open-checksum> tag generated
>> for that file.
>
> Did anyone ever get to look at this? Last time I checked (5.3.11) this was
> still broken. What would be the best way for me to help get to the bottom of
> the issue?
>
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.
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.
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.
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).
hth
73 de Jeff
> Thanks,
>
> JH
>
> ______________________________________________________________________
> RPM Package Manager http://rpm5.org
> Developer Communication List rpm-devel@rpm5.org
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
