Re: adding different compression types to createrepo

On Fri, 2010-08-06 at 12:02 +0200, Duncan Mac-Vicar P. wrote:
> On 08/04/2010 04:28 PM, seth vidal wrote:
> > Then what does it matter to you if there are xml files or not; if you're
> > just converting whatever data you have into .solv files?
> Because that will force everyone else to reimplement their tools using a 
> design that is based on a implementation and not the other way around.
> > Do you realize how combative your tone is? Is that on purpose?
> 
> I am not combative, really. I actually feel sad.
> 
> We have invested so much time in following what you guys do in every 
> possible aspect, the metadata, we moved our updates to updateinfo.xml, 
> changed the whole wording of channels/sources to repositories.
> 
> We took all SUSE weird changes to rpmmd and put them as extensions. We 
> started to deprecate the old susetags format for rpmmd repositories.
> 
> All this just to make the rpm world better and interoperable. The 
> openSUSE build service can build for SUSE/Fedora/Mdv distros, and of 
> course the generated repositories are rpmmd-based.

 It's nice that you've done work internally to be interoperable, we've
done the same thing with yum. It'd be much nicer if you shared more of
the upstream burden :).

> If yum will manage the repodata format tied to Fedora's specific 
> implementation, that means that _IMO_ rpmmd is just not ready to be the 
> rpm metadata format.

 How is it yum/Fedora specific? Zypper is now the only major program
which doesn't understand sqlite for primary/filelists/other. And, as
I've said explicitly before, XML support isn't going to be removed
anytime soon (although I wouldn't be shocked if --database-only because
_default_ within the next 12 months).

 And, yes, if you assume that you are going to take a significant
conversion hit everytime the repodata changes ... then it probably
doesn't matter much if that conversion is from XML or sqlite.
 But, with my yum hat on, I don't make that assumption and I see no good
reason to do so. It often requires more work, not having a perfect
custom local repo. format, but that's life. And from the point of view
of using what the repodata provides, XML is much slower.