[Rpm-metadata] files listings

[Jeff Licquia]

On Wed, 2003-10-22 at 17:11, seth vidal wrote:
> > 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.

>From a Debian perspective, NEVRA and checksum would be equally good as
identifiers, so do what makes the most sense.

> > 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.

Right.  But...

> 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.

That's why I asked.  I could see good reasons for allowing file data in
the main file.

> > 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?

No idea, but the possibility seems to be a win from my perspective. 
Debian, at any rate, shouldn't need anything like that.

> > 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.

Right.  I was responding to Jeff J's problem, which (it turns out) I
misunderstood.