[Rpm-metadata] files listings

[Jeff Licquia]

On Wed, 2003-10-22 at 07:48, Jeff Johnson wrote:
> seth vidal wrote:
> >but how to uniquely id the packages - should we use the package
> >checksum? or would nevra be sufficient, or maybe just the filename as it
> >is listed in the metadata file.
> 
> Header+payload md5 digest is unique but has the following drawbacks:
>     a) id is too unique, the file lists will need to be regenerated each 
> time the package is rebuilt.

Past experience with apt suggests to me that this should probably be
done anyway.

>     b) is rpm specific.

If the ID were clued in on the <checksum> tag in the package entry, it
wouldn't be specific to RPMs.  As an example:

<package type="deb">
  <checksum sha1="foo"/>
</package>

[...]

<package checksum="foo">
  <file/>
</package>

Of course, this is an artificial incompatibility for illustration
purposes, but you get the idea.

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

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>

I could see this as being useful for transition purposes and all-around
flexibility.

> NEV (R and A if you must) changes about on the right time scale that 
> file lists would not need to be
> continually updated. But there will be some (minor) loss of information 
> with files changing.

Debian doesn't allow package rebuilds without NEVRA changes, so maybe
I'm just missing something.  But it doesn't seem possible to rebuild
without regenerating the metadata.

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

> ><package someidentifier attribute>
> >  <file>/some/file/name</file>
> >  <file type='dir'>/some/dir</file>
> ></package>
> >  
> >
> 
> Paths with type please.

I like this too.  It also allows some flexibility:

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

> There are issues with directories that are created, but are not "owned", 
> by a package that can/will
> cause confusion.

Don't you have this confusion anyway, and on all kinds of files?

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?