changelogs in packages and space use

[seth vidal]

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 :)

-sv