Richard W.M. Jones wrote:
%changelog -f <changelog_file>
%changelog -g <git_repo>
And, I suppose:
%changelog -s <Subversion_repo>
%changelog -c <CVS_repo>
%changelog -m <Monotone_repo>
%changelog -h <Mercurial_repo>
%changelog -a <Arch_repo>
%changelog -b <Bazaar_repo>
... and so on, right? And every time someone comes up with a new version
control system, RPM would grow support for a new protocol and a new
changelog format? OK, but what format should it read when the -f option
is used? I'm not aware of a formal standard format for hand-written
changelogs.
What should RPM do if it encounters a parse error in the upstream
changelog? Should it fail to build the package?
%release_notes -f <release_notes_file>
And what would that mean? Should that entire web page be copied into the
update announcement? Including stylesheets and images? Or should the
update announcement only contain a link to the release notes?
The packager has to do two things (point RPM at the upstream
changelog
and the release notes), once, and the other tools should work from
those forever more.
So you expect upstream to keep their release notes in an ever-growing
document at a static URL? Or do you expect them to adhere to a strict
pattern so that you can insert "%{version}" in the URL? How common are
those approaches? Some projects do release announcements in a blog-like
style without any particular pattern for the URLs.
You could extend this later so it parses out specific version
information from the release notes, but the above covers about 80% of
it.
What language should it parse then? I'm not aware of a formal standard
format for release notes. All you can assume is that it will be some
kind of vaguely HTML-like tag soup. It may even be valid HTML, but HTML
doesn't contain anything that would help you extract the release notes
for a specific version.
Björn Persson