Dne 25.10.2016 v 13:03 Neal Gompa napsal(a):
On Tue, Oct 25, 2016 at 6:35 AM, Richard W.M. Jones
<rjones(a)redhat.com> wrote:
> On Tue, Oct 25, 2016 at 09:14:14AM +0200, Vít Ondruch wrote:
>> So why don't we optionally split changelog out of the .spec file?
>> Something like this might be first step:
>>
>>
>> $ sed -n '/^*/,$ p' ruby.spec > ruby.changes
> The problem with this is the first time there is a mass rebuild, or a
> packager uses rpmdev-bumpspec, or we just have a naive packager who
> doesn't understand what's happening, you'll end up with:
>
> %changelog
> * Fri Oct 21 2016 Some One <someone(a)example.com> - 2.3.1-59
> - Mass rebuild.
> %include %{SOURCE100}
>
> which will cause all sorts of problems (changelog will likely be out
> of order for a start).
I agree, that was idea for start. Of course rpmdev-bumspec and fedpkd
clog and similar would need some adjustments.
On the other hand, your example actually does not break anything, it is
just a bit inconsistent. Nothing which I could not fix next time I'll be
updating the package. This is something similar to -bumpspec addint .1
after NEVR.
>
> SUSE deleted all their RPM changelogs a very long time ago, we should
> do the same.
It seems to be baked into their build system, since their tool which
modifies the .spec file in-place. But we are probably looking into
something which fits better into RPM ecosystem.
It would probably be better if %changelog grew a "-f" flag
so that you
can point it to a file instead of using %include. It's also idiomatic
(we do this for %files lists, too).
I like the idea, although something like %include_chagelog macro would
do the job as well. What I dislike about my initial proposal is the need
of %{SOURCE} macro. Not sure if the '-f' flag would do better job here.
Vít