Hello,
I've noticed that a lot of packages going in to Factory does not have "proper" Changelog entries as explained to me (ie, copy redundant information from NEWS/Changelog entries upstream and put it in <packagename>.changes).
My question is, do we have a project wide policy for this, or would it be enough to add what has been done by the package updater (ie, update to version x.y.z, add/remove patch etc)?
Personally, I am in favor of not having to put it what changed upstream, since in most cases, this would be contained in a NEWS/Changelog file anyway.
Thanks, Magnus
On Fri, 30 Jan 2009, Magnus Boman wrote:
Hello,
I've noticed that a lot of packages going in to Factory does not have "proper" Changelog entries as explained to me (ie, copy redundant information from NEWS/Changelog entries upstream and put it in <packagename>.changes).
My question is, do we have a project wide policy for this, or would it be enough to add what has been done by the package updater (ie, update to version x.y.z, add/remove patch etc)?
Personally, I am in favor of not having to put it what changed upstream, since in most cases, this would be contained in a NEWS/Changelog file anyway.
Well, there have been requests and (internal?) policy that an entry with just
* New upstream version 1.2.3
is not appropriate and that we indeed _should_ paste in (IMHO redundant and not appropriate for the rmp .changes) contents from NEWS/Changelog.
So - we are just doing what is requested.
Yes, I think that the rpm .changes is to document _packaging_ changes and not package changes.
Richard.
* Richard Guenther rguenther@suse.de [Jan 30. 2009 07:57]:
I've noticed that a lot of packages going in to Factory does not have "proper" Changelog entries as explained to me (ie, copy redundant information from NEWS/Changelog entries upstream and put it in <packagename>.changes).
My question is, do we have a project wide policy for this, or would it be enough to add what has been done by the package updater (ie, update to version x.y.z, add/remove patch etc)?
Personally, I am in favor of not having to put it what changed upstream, since in most cases, this would be contained in a NEWS/Changelog file anyway.
Well, there have been requests and (internal?) policy that an entry with just
- New upstream version 1.2.3
is not appropriate and that we indeed _should_ paste in (IMHO redundant and not appropriate for the rmp .changes) contents from NEWS/Changelog.
So - we are just doing what is requested.
Yes, I think that the rpm .changes is to document _packaging_ changes and not package changes.
Back when I was in-house I advocated to copy Changes, NEWS, whereever the changelog for the software itself is, and I still do. It's very convienient to be able to access this information when off-line, etc.
For sheer convienience it's great.
Besides. It's the changes to the software, hence the package. If you dont want it, it should be called package-container changes.
On Fri, 30 Jan 2009, Mads Martin Joergensen wrote:
- Richard Guenther rguenther@suse.de [Jan 30. 2009 07:57]:
I've noticed that a lot of packages going in to Factory does not have "proper" Changelog entries as explained to me (ie, copy redundant information from NEWS/Changelog entries upstream and put it in <packagename>.changes).
My question is, do we have a project wide policy for this, or would it be enough to add what has been done by the package updater (ie, update to version x.y.z, add/remove patch etc)?
Personally, I am in favor of not having to put it what changed upstream, since in most cases, this would be contained in a NEWS/Changelog file anyway.
Well, there have been requests and (internal?) policy that an entry with just
- New upstream version 1.2.3
is not appropriate and that we indeed _should_ paste in (IMHO redundant and not appropriate for the rmp .changes) contents from NEWS/Changelog.
So - we are just doing what is requested.
Yes, I think that the rpm .changes is to document _packaging_ changes and not package changes.
Back when I was in-house I advocated to copy Changes, NEWS, whereever the changelog for the software itself is, and I still do. It's very convienient to be able to access this information when off-line, etc.
For sheer convienience it's great.
Yeah. Sort of. For convenience I like the Debian way that has
/usr/share/doc/$package/changelog.Debian
in addition to recommended packaging of
/usr/share/doc/$package/{ChangeLog,NEWS,README} (or whatever it is called)
The changelog.Debian mentions package-container changes _and_ software changes that fix reported bugs (with a #1234 marking, Debian auto-closes bugs on checkin via parsing the changelog.Debian).
Richard.
Mads Martin Joergensen mmj@mmj.dk writes:
Back when I was in-house I advocated to copy Changes, NEWS, whereever the changelog for the software itself is, and I still do. It's very convienient to be able to access this information when off-line, etc.
For sheer convienience it's great.
I consider it very unconvienient esp. because contents and format of said files look different in all these upstream packages. I'd rather would like us to summarize upstream changes consistently. This would mean real work and nobody dares to ask for it...
Besides. It's the changes to the software, hence the package. If you dont want it, it should be called package-container changes.
Otherwise Richard is right that .changes should mostly about packaging related changes, and, from there concerning a perfect GNU package you should just reference
http://www.gnu.org/software/<package>/NEWS.<version>
or something very similar.
-
Karl Eichwalder -
Mads Martin Joergensen -
Magnus Boman -
Richard Guenther