Hi Nicolas,
Nicolas Mailhot <nicolas.mailhot(a)laposte.net> writes:
> How do I let rpm generate the changelog automatically?
This feature is not changelog generation, just changelog bumping on
build events. You still need some other method to put non-build events
in the changelog.
The detached changelog is just one more file in SRPM sources, which is
modified by rpmbuild at `%build` time with other files rpmbuild
modifies. The tricky part is to modify the source file as a source file
so rpmbuild adds the result to the produced SRPM (and, that does not
work in mock right now, because mock serves the SRPM that existed at
the start, not at the end of the build. Though it’s probably just a
matter of getting mock to call again its SRPM creation method at the
end of the build).
So essentially you store the changelog in a separate file (like it is
done in openSUSE) and use that to calculate the next release field?
Given the other replies to this thread (that this is all local only,
unless koji does git commits), does that mean that it's still: dist-git
commit = rebuild. The "only" difference to the current state of affairs
being, that I don't have to specify the Release field myself?
The packager does not have to request the modification in his spec,
it’s done as part of the various %auto_foo calls the change introduced
Could you provide an example how this would look in practice?
> And is this related to Piere/Pingou's work on the same topic that was
> deployed to koji staging?
It’s a different implementation, at the rpm level, that does not tie
bumping to Fedora infra (koji included). Though, it is probably
complementary to what pingou did on the changelog alimentation front.
IMHO the design mistake so far was to conflate bumping and non-build
event changelog filling. You need to do both of course but build event
should be a build event driven by the lowest common denominator
(rpmbuild) with koji/infra scrapping rpmbuild results as usual and
exposing them to users.
This is a good point imho: not every rebuild warrants a changelog entry
and having both separated appears sensible to me.
What I am currently missing from this proposal though is:
- How is this actually even implemented?
- How will this look in practice?
- Given that additional files would be put into dist-git, how do we roll
this back in case things go wrong? (Having thousands of "remove
%autorelease" commits by releng could be an option here, albeit not a
pretty one).
Cheers,
Dan