On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf <malkodan@xxxxxxxxx> wrote:
15K is nothing. Really. I like to see the whole history of a package, it's nice and fun.That's around 50K, and compressed (RPMs are compressed):Hey,I tend to be against trimming. I was just looking at the binutils changelog (goes back to 1997):
$ rpm -q --changelog binutils | wc -c
54984
$ rpm -q --changelog binutils | gzip | wc -c
15552Perhaps other packages has larger changelogs. I guess common sense is what we should use, but generally speaking I'd say don't trim, as it doesn't really matter and it's cleaner to have a full changelog, rather than a story which starts somewhere in the middle.
Just out of curiosity, what packages have huge changelogs?
A lot of them are the ones you'd expect -- toolchain-related packages that have been around forever like gcc, gdb, glibc. SELinux related packages have pretty huge changelogs, too. I think the winner for greatest changelog growth rate is likely rhc (the OpenShift client): over 350 entries in less than two years. :-)
Andy
BR
Dan Fruehauf.On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter <rdieter@xxxxxxxxxxxx> wrote:
Richard Hughes wrote:
> Is there any guidance as when to trim %changelog down to size? Some
> packages have thousands of lines of spec file dating back over 15
> years which seem kinda redundant now we're using git.
To me, common sense dictates that it's perfectly ok to trim the length of
the changelog as long as items that are relevant to the current release are
kept intact. Use your best judgement where that position lies.
-- rex
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
