[Rpm-metadata] discussion of createrepo and repodata format future

[seth vidal]

On Fri, 2010-08-06 at 14:51 +0200, Michael Schroeder wrote:
> > the equivalent of: yum install /usr/bin/myprogram
> 
> This would work because /usr/bin/ files are in primary.xml.
> libzypp doesn't support on-demand download of the filelist,
> libsatsolver offers an interface for it.

rhel/fedora has a fair number of non *bin/* filedeps that we have to
look up. And try as I might, I can't seem to make that number go down.



> Well, that depends on the usage pattern. As zypp doesn't support
> to download the filelist, we make sure that there are no (Build)Requires
> to files outside of the "primary" filepatterns. As /bin and /usr/bin
> are used in many packages, we need to download the file information
> for those directories anyway, so moving them from primary into seperate
> files makes things worse for us.


B/c of the extra file to download? B/c the size shouldn't change. With
some of the suggestions in changing of primary, I'd think the size
should decrease overall.

Did you have any thoughts on the suggestion of breaking summary and
description out into translatable files?


> > 
> > In fact my original thoughts were that repomd.xml doesn't need to
> > change, except to add an attribute of 'compression type' to each
> > datatype.
> 
> Oh, that's also what I was thinking of. I didn't like the "primary_lzma"
> type because it's not different data, but just a different representation.

I agree - but for backward compat that was the only sane way to keep
from breaking all the existing parsers.

> I'd prefer:
> 
>   <data type="primary">...</data>
>   <data type="primary" flavor="lzma">...</data>
>   <data type="primary" flavor="sqlite">...</data>
> 
> But I don't know how many repomd parsers would choke on this...

Probably a lot of them would choke on it. Pretty sure yum would pick one
of them at random.


Nitpick but: if I never see 'flavor' as a descriptor of something that
is NOT food, that'll be fine. It's like file 'colors'. That just makes
me want to scream whenever I read it.


> Speaking of that lzma patch, I pretty much opposed it because it
> conflicts with the "delta download" mechanism I implemented some weeks
> ago. The idea is to use 'gzip --rsyncable' for gz compression, add 'zsync'
> checksum data to the metalink files and let libzypp download just the
> changed blocks with range requests. Works quite nice for our maintenance
> updates, it's proably not very useful for Factory (i.e. "rawhide") where
> the number of rebuilds is quite high.

Where is this patch?

-sv