On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen <pmati...@redhat.com> wrote:

> On 02/09/2018 03:34 PM, Josh Boyer wrote:
>> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mat...@fedoraproject.org>
>> wrote:
>>> On Thu, Feb 08, 2018 at 05:02:10PM +0100, Igor Gnatenko wrote:
>>>> It seems that a lot of people have %file, %check, %build, %whatsoever
>>>> in their changelog section.
>>>> Is there any reason I should not go and automatically escape them?
>>> This seems like a lot of churn. If we're going to do this, let's go big
>>> and get rid of RPM changelogs.
>>> When we have a package update, there are basically two different kinds
>>> of changelog information. Well, three.
>>> First, there's the upstream changelog. We don't generally do much with
>>> these except maybe package as %doc.
>>> Second, there's package maintainer changelogs. These are really
>>> redundant with the dist-git log. We don't really need this anymore.
>>> It's just a chore.
>>> Third, though, there's end-user information. Why should a user care
>>> *This* is redundant with bodhi update info, at least if packagers fill
>>> that out, and it often also duplicates upstream changelogs, *and* it
>>> often also covers things like "fixes CVE-####' also carried the
>>> specfile changelog.
>>> This is neither most helpful for user *nor* ideal for packages. Why
>>> don't we drop changelogs entirely in favor of 1) using the dist-git
>>> logs for specfile maintainers and 2) providing the end-user information
>>> in a different way. This could be through specially formatted log lines
>>> going with the commit, or it could be simply in a standard separate
>>> file (`fedora.user-visible-changes`). Optionally, it could include both
>>> a high level end-user summary, and a detailed description for sysadmins
>>> and the curious.
>>> Wherever it lives, this would be read by Bodhi, so there's
>>> would be need to enter it more than once. And, perhaps a DNF plugin
>>> could be made to read and display this information for systems
>>> administrators.
>> I fully support the removal of RPM changelogs.  However, you've missed
>> two cases:
>> 1) Rawhide, which doesn't go through bodhi
>> 2) Fedora release upgrades, which don't go through bodhi
>> Now, I would actually LOVE for Rawhide to go through bodhi but
>> whatever.  The release -> release upgrade isn't really solvable that
>> way though.
>> Someone else suggested changelogs could be inserted during koji build
>> time.  That would be interesting to look into.
> Koji, or fedpkg, or better yet some hook in rpm itself. It's not exactly
> rocket science we're talking about here if people are ready to give it a go.

I actually looked yesterday if I could make a PR for rpm implementing it
but I couldn't really find a good way to do it. So I decided to implement it
in `rpkg-client` (https://pagure.io/rpkg-client/branch/spec_preprocessor -
basically a hack upon python-rpkg library) by spec preprocessing. So,
with that development version of rpkg, you can have specs (or rather spec
templates) like this in your Git project:

Name:       {{{ git_name }}}
Version:    {{{ git_version }}}
Release:    1%{?dist}
Summary:    This is a test package.

License:    GPLv2+
URL:        https://someurl.org

Source: {{{ make_source }}}

This is a test package.

{{{ setup }}}

{{{ git_change_log }}}

rpkg will take that spec template and replace the {{{ ... }}} tags with
standard output of the commands inside the braces (git_name, git_version,
make_source, setup, git_change_log are all shell functions). Afterwards,
the generated spec is used to e.g. create an srpm (done by `rpkg srpm`

I haven't actually implemented the `git_change_log` function yet (nor the
other functions except for `make_source`) like Igor did - currently it just
always returns '%changelog' and that's it but I wanted to show this to
possibly get some feedback.

Thank you

> Neal, doesn't Mageia (and Mandriva) pull package changelogs from SCM
> already? Do you know what kind of hook they're using? Actually I think Suse
> does this too so Fedora is probably again the last one to adopt this...
>         - Panu -
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to