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
