On Fri, 2019-11-08 at 11:17 +0100, Stefan Seyfried wrote:
Am 08.11.19 um 10:45 schrieb Dominique Leuenberger / DimStar:
In all honesty: a package that did not change in 5 years probably does not carry that much weight in its changelog anyway that it would matter.
Then why does rpmlint complain if there is no changelog?
You decide to believe the output of scripts/bots as it fits your purpose, right? Since when are YOU the one NOT questioning the usefulnes of any such bot/script?
OK, i assumed that "empty changelog" would be deemed "bad idea" by everyone. "empty changelog" is what I get from enterprise software vendors in their proprietary-crap rpms. I wish we could do better.
Now that you advocate it as a good idea, please accept my apology and I rephrase the above sentence:
I'm not advocating 'empty changelogs' per se. But I'm advocating a cut- off date in the binary shipped rpm changelog. And short of RPM offering a mix to at least att one entry and picking one even if it would have to go past the cutoff date, this is a sad consequence happening. simple fix: Submit a 'Remove group tags', add a changelog entry :) and all is good.
"It is stupid to remove all changelog entries."
They are not 'removed' - they are 'just not added'
years of changelogs, on a distro that is almost daily updated.
This is a package that is useful and builds without any gcc warnings etc. since 2016-04-10, and still I consider the changelog important and if it only to find out "when was this last touched".
yes, sure.. and if nobody would have mentioned that this package made the script barf that creates diffs of the DVDs you'd have found out about this in December 2029 - and nobody would have cared. Or when exactly did you last read the changelog of exactly that package?
And it is ONLY the changelog in the binary rpm... the package changelog in the changes file stays fully intact for the packagers.
Yes, but it is totally unaccessible on a production system.
Oh.. sure.. and even if it were accessible, khmeros-fonts.changes contains sooo many important things. I'm sure you are no longer able to perform your daily tasks as you no longer can check when Khmeros-fonts was renamed to khmeros-fonts.
And note that almost nobody can really tell easily later on which source version in OBS corresponds to the given binary rpm. (I try to do this often trying to find the changes between kernel-default.rpm, kernel-default.PTF.rpm
I know: it's against your nature to receive information on how to do things, as it further weakens your arguments, but:
rpm -q --qf "%{SOURCERPM} %{DISTURL}\n" aaa_base aaa_base-84.87+git20191017.bf0a315-1.1.src.rpm obs://build.opensuse.org/openSUSE:Factory/standard/85bd40e671cec211224116fcb2a1b29d-aaa_base
I intentionally added %{SOURCERM} in plus - just for the case that this would have been a sub package of some obs built package.. in this case we learn, that this was built from the source rpm aaa_base… (version/revision), so coming from the OBS source package aaa_base. osc co openSUSE:Factory aaa_base -r 85bd40e671cec211224116fcb2a1b29d Et voila.. that's the source used to build this very package.
Different strategies could be nice for RPM - a mix between max number
of entries vs age - but that's nothing RPM offers.
That would certainly be a useful feature, but given who maintains rpm in Factory, I don't dare trying to send a patch.
I woulnd't have expected anything else. Cheers, Dominique