On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf <malkodan(a)gmail.com> wrote:
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
That's around 50K, and compressed (RPMs are compressed):
$ rpm -q --changelog binutils | gzip | wc -c
15552
15K is nothing. Really. I like to see the whole history of a package, it's
nice and fun.
Perhaps 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(a)math.unl.edu> 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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/devel
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel