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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
