Re: discussion of createrepo and repodata format future

On Fri, Aug 06, 2010 at 08:34:15AM -0400, seth vidal wrote:
> Something that we've kicked about is mix-and-match metadata fileformats
> based on what makes accessing them most functional. I know opensuse
> doesn't have to muck with filedeps in pkgs but do you resolve them for
> when a user knows the filename they need but not the pkg name?
> 
> 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.

> If so - the discussion of breaking of the filelists into chunks based on
> subdirs might be beneficial to you.

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.

> > Another problem that shows up is that caches may be different. For 
> > example, yum has one file per metadata. We have just one solv file per 
> > repository. But I guess that is just another tag under repomd tag. 
> > Specifying the location, and the format, so that the downloader can 
> > choose whether to use it or not.
> > 
> > Also, what is the status of these tags?
> > 
> > <revision>1277771829</revision>
> > <tags>
> > <repo>obsrepository://build.opensuse.org/openSUSE:11.2:Contrib/standard</repo>
> > </tags>
> 
> They shouldn't need to change at all.
> 
> 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'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...

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.

Cheers,
  Michael.

-- 
Michael Schroeder                                   [email protected]
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}