Lack of update information

Richard W.M. Jones rjones at redhat.com
Mon Jan 26 17:43:31 UTC 2009


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:

$ zless repodata/primary.xml.gz
[...]
<package type="rpm">
  <name>mingw32-portablexdr</name>
  <arch>noarch</arch>
  <version epoch="0" ver="4.0.11" rel="1.fc10"/>
[...]
  <summary>MinGW Windows PortableXDR XDR / RPC library</summary>
  <description>MinGW Windows PortableXDR XDR / RPC library.</description>
  <packager></packager>
  <url>http://et.redhat.com/~rjones/portablexdr/</url>
  <time file="1227118253" build="1227118253"/>
  <size package="33005" installed="104342" archive="105656"/>
<location href="RPMS/mingw32-portablexdr-4.0.11-1.fc10.noarch.rpm"/>
  <format>
    <rpm:license>LGPLv2+</rpm:license>
    <rpm:vendor/>
    <rpm:group>Development/Libraries</rpm:group>
    <rpm:buildhost>intel-mb</rpm:buildhost>
[...]

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.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/




More information about the fedora-devel-list mailing list