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?

BR
Dan Fruehauf.


On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter <rdie...@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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Reply via email to