Mailinglist Archive: opensuse-packaging (186 mails)

< Previous Next >
[opensuse-packaging] Changelogs need changes?
  • From: anicka@xxxxxxx
  • Date: Tue, 24 Feb 2009 16:55:27 +0100
  • Message-id: <20090224155527.GA26899@xxxxxxxxxxxx>
Hello!

I would like to discuss here one aspect of our changelog policy.

Unlike other distributions, we have an unusual rule for our RPM changelogs
(.changes file): when updating to the new version, we must process an upstream
changelog and copy the most important things to RPM changelog. I would like to
discuss this policy and its problems and benefits.

When this policy became effective, I have heard about two reasons for doing it:
1. Maintainer who does the update is aware of the changes in upstream.
2. We have easily accessible information about upstream changes.

As for the first plus, yes: Maintainer is really pretty well aware of all the
information because he not only reads the changelog, but he also spents a great
amount of time copying it, pasting it, trying to shrink it as most as possible,
reformatting it and so one. I do not want to speak for other packagers (their
stories might follow), but I have spent countless hours tweaking my scripts for
automagical processing the changelogs and although it saved me loads of time,
it is the only thing I regularly have to fix manually during my otherwise
automatical perl module updates. It is boring and IMHO completely useless work
that costs us lots of time that we could spend on hacking something useful.

As for the second plus, I am not aware that anyone uses this information. AFAIK
we have no tool to present it to our users in a neat way. It is even not a part
of the package metadata, so if you want to get it, you must get the complete
package - and if you got the package, you can equally easily see upstream
changelog with the same information, that you could get from the changelog.

Sure, you might say that we should use RPM changelogs just for the most
important changes to save our users time of searching for them. But a brief
look at our packages shows that we are not doing it and usually we even cannot
do it - how to pick up the most important changes from 30 minor bugfixes? How
to pick them from a loads of new features in a new major version? We can either
duplicate the changelog (usually unfeasible) or randomly pick up some news
(this is my most usual choice) to make our policy happy.

In fact, when you are interested in upstream changes, in almost every case it
is more useful to take a look to upstream changelog because it is complete and
better structured. When you are interested in specfile changes instead, you
cannot just read them, you have to skip tons of useless information from
upstream changelog - in fact, even when there is no upstream changelog, it
would be better to maintain some as a patch than to pollute RPM changelog with
a noise.

I think that we spent countless hours of time working on something that no one
is interested in. Even its very presence might be annoying in some cases.
Should we really continue doing it? Would not be better to just go back several
years and start to do it like others do it?

Reference:
http://en.opensuse.org/SUSE_Package_Conventions/Changelogs#11.4_Sourcecode_changes

Anicka
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx

< Previous Next >