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