Tobias Gerschner wrote: >> Wouldn't be hard to fix, is on my todo++ list, but there's been zero >> interest in using rpmrepo so far, hence its a low priority. >> >> You know where http://launchpad.net/rpm blueprints are.
[...] > OTOH switching to a format which is mainly driven by a community that does > not seem keen to collaborate is not very pleasing either. > > Has anyone any links/ information about the reasons as to why repo-md has the > format that it has today? Think it went from the first extracted rpm headers (.hdr) to XML metadata (xml.gz) to SQL metadata (.sqlite.bz2)... Your best guess is http://createrepo.baseurl.org/ and http://lists.baseurl.org/mailman/listinfo/rpm-metadata > Is there any interest to review this format and potentially come up with a > new blueprint? While I am personally very interested in sorting this I can > only see this work with input and support from multiple drivers which would > then collaborate on this new format and actually use it. I don't just want to > do it my way, but have an accepted, comfortable solution that is well > engineered and has a good future with rpm5. I'm pretty certain that whatever createrepo/repodata does for a new format, it will Require yum and Conflict rpm5 ? http://lists.baseurl.org/pipermail/rpm-metadata/2010-August/001209.html http://lists.baseurl.org/pipermail/rpm-metadata/2010-August/001233.html > Any thoughts? Is there an option/ solution I am missing? There is the mixture of rpm headers and xml metadata that urpmi is using, or using a rpmdb directly perhaps ? But changing the "pkgid" (to not include the payload) and adding partial downloads sounds like improvements... --anders ______________________________________________________________________ RPM Package Manager http://rpm5.org User Communication List [email protected]
