Hello, 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 }}} %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@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
