F-14 Branched report: 20100923 changes

Przemek Klosowski przemek.klosowski at nist.gov
Fri Sep 24 17:11:28 UTC 2010


On 09/24/2010 12:43 PM, Peter Robinson wrote:
> On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi<a.badger at gmail.com>  wrote:
>> On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
>>> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
>>>> Is it really necessary to include entire package change logs in the
>>>> rpm changelog? What is wrong with referencing either the included
>>>> changelog or a URL to a changelog that people can go and reference. I
>>>> remember this being discussed ages ago but I'm not sure if there was a
>>>> packaging policy instigated.
>>>
>>> Along the same lines, why should we have RPM %changelog at all?  The
>>> git repo should maintain the changelog which can be automatically
>>> integrated with the binary RPM at build time.  At the moment we have
>>> the same information in at least 2 places.
>>>
>> We need to have the rpm changelog in the rpm so that the end user's can see
>> it.
>
> For the fact that its gone from version X to version Y yes. For the
> actual application changed between version X and version Y they can
> see the ChangeLog that's in the %doc or alternatively check the
> release notes for the new version upstream (which can be easily
> provided as a link in the rpm changelog). I just don't see the point
> in duplicating hundreds of line of upstream release notes in the rpm
> changelog when all that's actually changed in the rpm is that we've
> gone from release X to release Y.

It is extremely useful to see the RPM info on which vulnerabilities
(CVS numbers, etc) were fixed by the update, especially when they are 
backported and therefore not reflected in the package version number.

In principle, the system for extracting %changelog from git might work,
with two provisos:

- people understand that git changelogs have slightly different purpose 
than RPM changelogs: git records 'what' changed, while RPM should also 
tell 'why' it was changed. In other words, we'd be relying on developers 
making high-level as well as low-level comments in the 'log.

- the volume of changelog output should not overwhelm useful information 
contained in the log.


More information about the devel mailing list