Re: Escaping macros in %changelog

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 8, 2018 at 1:32 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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.

josh
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux