changelogs in packages and space use

David Cantrell dcantrell at redhat.com
Fri Aug 31 14:46:34 UTC 2007


On Fri, 31 Aug 2007 09:52:28 +0300 (EEST)
Panu Matilainen <pmatilai at laiskiainen.org> wrote:

> On Fri, 31 Aug 2007, seth vidal wrote:
> > On Fri, 2007-08-31 at 08:30 +0200, Ralf Corsepius wrote:
> >> On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
> >>> On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
> >>>> On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
> >>>>>
> >>>>> 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> >>>>> it for the repodata
> >>>>>
> >>>>> 2. trim repos at rpmbuild time - great - I've suggested it as an option
> >>>>> to rpmbuild on rpm-maint list.
> >>>>>
> >>>>> 3. trim them out of the pkgs the next time we change a package. Just
> >>>>> prune them down to the last years worth of changelogs - maybe saving the
> >>>>> old changelogs in a file in the cvs repository - or even into an unused
> >>>>> source file in the srpm?
> >>>>>
> >>>>> What're people's thoughts on this?
> >>>>
> >>>> 3 is a data loss of possibly useful info, and 1 doesn't help rpm
> >>>> download size. I think clearly proposal nr 2 is the best.
> >>>
> >>> okay - then if 2 is implemented in rpm then I'd suggest we limit it to
> >>> the last year, that's two releases-worth of changelogs -it should cover
> >>> reasonably well.
> >> Hmm, I am not convinced that this is a good move, because such a
> >> "time-based pruning" is a pretty random/arbitrary criterion, which is
> >> not necessarily related to a changelog entry's value.
> >>
> >> The same applies to "n-th last entries" or "size-based pruning".
> >>
> >> Instead I'd prefer "source-level downsizing", i.e. maintainers to keep
> >> their changelog's in "reasonable shape".
> >>
> >
> > the time based pruning would only be in the produced rpms - not in the
> > actual spec file. And if we have a package which is gone a year w/o
> > being touched in anyway that touches the changelog - maybe that's a
> > problem :)
> 
> What buggers me most about this whole discussion is that we're treating a 
> symptom, not the disease. Adding an option to rpmbuild to cut the 

Thank you.  I was waiting for someone to mention that.  Treating the symptom is not the right answer.

> changelogs where desired is no big deal, but the real issue IMO is that 
> there's an enormous amount of redundancy in the changelog data. All of it 
> is carried as a separate copy in
> - each binary rpm and it's possible subpackages
> - likewise for rpmdb itself for installed packages
> - src.rpm header
> - in the spec inside src.rpm
> - repository metadata (several times due to subpackages and src.rpms)
> 
> That's helluva lot of duplicate data when you're transferring it over the 
> wire...

Everyone likes to talk about use cases, so let's go down that road.  What are the use cases for the RPM changelog data?

1) Like many people have said, I like to 'rpm -q --changelog' an RPM to see what has changed.  Especially if its functionality has changed from what I know.  Maybe it's desired or undesired, but the changelog gives a quick indication.

2) People like to query the changelog in the RPM to look for specific bug numbers.

What else?

We can still deliver that to the target system.  Panu has already pointed out that we already deliver the changelog at least 5 times over.  We should figure out where to put this information once and still be able to deliver it to the target system.

Arbitrarily deciding to remove all changelog entries older than 1 year is stupid.  For some packages you'll end up with one entry (or none!) and for some packages you probably won't make a dent (kernel?).

-- 
David Cantrell <dcantrell at redhat.com>
Red Hat / Westford, MA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070831/7babafed/attachment.sig>


More information about the fedora-devel-list mailing list