Lack of update information

[seth vidal]

On Mon, 2009-01-26 at 17:50 +0000, Richard W.M. Jones wrote:
> On Mon, Jan 26, 2009 at 12:45:12PM -0500, seth vidal wrote:
> > On Mon, 2009-01-26 at 17:43 +0000, Richard W.M. Jones wrote:
> > > On Mon, Jan 26, 2009 at 06:28:43PM +0200, Panu Matilainen wrote:
> > > > But what exactly would that solve? The ChangeLog file would be in the rpm 
> > > > payload, so the contents are only accessible after the package has 
> > > > already been installed.
> > > 
> > > Yum already pulls out lots of meta-info from the RPMs and stores it in
> > > its own database, eg:
> > > 
> > > It can equally pull out the changelog file (or part of it) if required.
> > > 
> > > > The intended audience here seems to be "end 
> > > > users", to whom the raw upstream SCM changelogs aren't often that useful. 
> > > 
> > > The stereotypical grandmum end user won't care about any of this
> > > stuff.  Giving people detailed changelogs is useful if you're trying
> > > to find out what *really* changed in the package.
> > > 
> > > Additionally the metadata is useful for other tools, eg. rpm2html
> > > which generates sites like http://rpmfind.net/
> > > 
> > > To be honest I can't see a downside to adding extra metadata to RPMs,
> > > except that someone has to write the code to do it.
> > 
> > And we potentially have to change the sqlite db format and the repodata
> > formats to accommodate them.
> 
> The repodata is in XML where the X stands for eXtensible.  Extra
> fields should be ignored if not used.

heh, that's quaint.

> 
> Typical SQL databases don't mind at all if you add extra columns to
> tables.  Whether this is true of the on-disk binary(?) format used by
> sqlite I have no idea, but if the sqlite format cannot handle such
> changes, then it surely must be the wrong format for the task.


I never said it couldn't be extended. But if we do add to it we should
have a good reason. That's all I said.
-sv