Hello,
On Fri, Feb 9, 2018 at 3:22 PM, Panu Matilainen <pmatilai(a)redhat.com> wrote:
On 02/09/2018 03:34 PM, Josh Boyer wrote:
> On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mattdm(a)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 }}}
%description
This is a test package.
%prep
{{{ 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`
command).
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
clime
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org