[Rpm-metadata] files listings

[seth vidal]

> One problem: what if a package entry provides multiple checksums?  Which
> do you use as the ID?  How would you know?

one of the reasons I'd be happy with nevra  - you know where and what it
will be on any package.


> Also, as an option, could file data be included with the rest?  Like:
> 
> <package>
>   <name/>
>   <version/>
>   <format>
>     <foo:depends/>
>   </format>
>   <file>/usr/bin/foo</file>
>   <file type="dir>/var/spool/foo</file>
> </package>

well one of the goals is to make the first file small enough so you
aren't downloading a huge 20MB file in one gulp.

Critical files like: *bin/*, /etc* and /usr/lib/sendmail, would be
listed in the main file and others in the files-only xml file. This is
partially an apt-ism and partially a suggestion by adrian and partially
a suggestion by the ximian/red carpet people. I think it makes a lot of
sense, actually.


> If metadata is only regenerated for NEVRA changes, and not for rebuilds
> of packages, how can one validate the checksums in the metadata file?

I think all the metadata gets regenerated on any change, period. It's
not a terribly costly process and would be worthwhile - there is some
concern about it making people redownload the metadata for changes - but
if the goal is for the first file to be, compressed, small enough to
cope with nicely, then they'd only need to download again if they
absolutely needed the complete file lists or other misc data.

> <file type="config/>
> <file type="char-device" major="foo" minor="bar"/>
> <file type="fifo"/>
> <file type="socket"/>

Do we need to carry this data along here?


> If a RPM depended on a generated file, the dep could be satisfied if the
> package generating it is already installed.  But if it isn't, how would
> a dep solver figure out which package to install in order to get that
> file?

That's the point of this file. Allow to find that ownership to traceback
to the package you'd need.


-sv