[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Lack of update information



On Mon, 26 Jan 2009, Jakub Jelinek wrote:

On Mon, Jan 26, 2009 at 01:17:40PM -0500, Bill Nottingham wrote:
Richard W.M. Jones (rjones redhat com) said:
*All* of that is in the RPM header. It's not pulling anything out of the
file payload.

So?  createrepo would need to parse a bit more of the RPM.

1) Having createrepo have to parse the entire cpio metadata to
look for a particular file would be insanely slow
2) I just picked a random package I maintain. The ChangeLog is
1.4MB uncompressed, 326k compressed. Even if that's larger than
typical, imagine scaling that out across 7000 source packages,
and then the size of the resulting XML to download...

In gcc ChangeLogs are 5.2MB bzip2 -9ed, glibc has 6.5MB of uncompressed
ChangeLogs (haven't checked how big they are compressed).  Putting that
all into metadata is going to grow it a lot.

...and the header data is not compressed whereas the payload is. It would not only hugely bloat the download size but rpmdb size too. And having it in metadata (ie in the header) would mean you'd have to use rpm --someswitch to access it, whereas it's on the filesystem now. All doable, but I *really* dont see the average upstream ChangeLog available as metadata worth all this.

Adding a "news" or "changelog" file attribute would cost exactly one bit of a bitfield, that would be quite another story. Except .. well, rpm already supports %readme and %license "file attributes", but nothing at all uses them for anything. Part of that is probably that they aren't compatible with %doc so they're pretty cumbersome to use in a spec. Maybe that'd be worth fixing, and at least licenses are something that would want special treatment anyway (ie get installed even with --nodocs)

	- Panu -


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]