Re: debian/changelogs, legacy work on packages and other distros
I guess you are addressing my actions in some cases where I adopted the
work which was done by somebody else. My handling was inspired by
probably only aural discussion with ftpmaster (I admit I have not found
any written document about this) who was bored about long pre-Debian
changelog entries which just consumes their time. If you are really
concerned about this topic I would suggest to move the topic to
debian-devel because I do not see the point to keep this hidden in the
Debian Med circle.
The last case where I'm guilty for this action is beast-mcmc. You can
inspect the changes I did in the changelog in SVN.
I would like to mention that I definitely needed to change the changelog
because the Closes statement needs to be in the latest changelog entry
and not in the first one. I contacted the former maintainer Felix
Feyertag including CC to the devel list. Usually I would have waitet
longer than just three days before taking action but I'm a bit under
pressure with these packages. If you look at the former changelog in
SVN you see only a series of "New upstream version" and anything
remains unreleased. There is nothing about packaging changes or
something like this. So I decided it was not worth keeping (and as we
have a VCS it is not definitely lost if somebody cares). (Moreover all
changelog entries of Felix were done with a broken ID which did not
had a valid e-mail address.)
On Sat, Feb 05, 2011 at 02:03:26PM +0100, Steffen Möller wrote:
> I have not seen it in the Debian policy document, yet, but at least for the packages I co-maintain with Ubuntu developers myself
> (all outside of Debian Med if I am not erroneous) and from what I read on the lists, it is common practice to just extend the
> debian/changelog file. It is never shortened.
I agree that a changelog of a package that was *released* at the Debian
mirror should definitely not be shortened (neither should it be forked
as release team forced me to do in gnumed-client 0.7.10 unfortunately).
I would even agree if there was a first release in Ubuntu or any other
derivative *and* we take over the packaging stuff that we should keep
the Ubuntu/other history in any case. Regarding never released packages
with no real information about packaging changes or things which should
really be kept in mind I consider it different.
> The idea behind this is that we all steadily improve the package, and knowing about
> the changelog allows to estimate the gain of functionality that may be observable in the one or other distribution. And of course
> it also helps to pinpoint to the one responsible for the good or the bad, without a dig in the repository's logs. One possible
> effect is that the debian/changelog is already fairly long before it first hists the Debian server. Nobody should mind.
> Another source of packages that I would want to render you aware of are those packages that we create for ourselves. Those, that
> are never truly meant to be uploaded to the servers. I personally for instance create a Debian package for about everything that I
> evaluate locally. And a basic package is fairly simple to create, so I just do it. It does not cost much extra time. And finally,
> the final package is just so much easier to get removed from the disk again after the evaluation. And I do not need to fiddle with
> the PATH too much. In most cases, such packages never go anywhere. But sometimes those are submitted to the Debian Med repository.
> And we just had the case, that for a recent release of T-Coffee, the structural alignment program TMalign was suddenly of
> interest. This was one of those "should be in Debian Med" packages that is kind of there but not really ready for an upload. The
> ITP pending because of a missing license file and then forgotten. It was then found by Tim who has then with support by Andreas
> completed the packaging. Lovely. In my mind, the debian/changelog file should then remain intact, i.e. not be resetted to a
> "Ininital release (Closes:..)" kind of minimalist version. The package had a previous life also outside the distribution. And we
> would weaken our community when we just forget about that initial development time. That reason not to upload may be technical or
> due to a temporary lack of interest. The package nonetheless should not forget about its history.
Just lets look at this case in SVN. IMHO you are mixing up two
1. Keeping the old history of the not yet uploaded package
2. Bluring our packaging changelog with upstream changelog
Item 1. is perhaps topic of discussion. I would not mind if you would
consider the pre-release changelog important and would like to add thhis
history. I would take the freedom to apply common sense if something is
really worth keeping but I would adapt to a "best practice" in our team
if you insist on this (it would be a good idea to fix this in our policy
However, item 2. injecting a verbatim copy of *upstream* changelog just
into our packaging changelog is simply wrong and I *intentionally*
removed this information which does *not* beling to our changelog *on*
purpose because of educational reasons. I know that Tim is a newcomer
and I just told him not to copy upstream changelog into the packaging
because this information is *not* about packaging. The information is
even *wrong* because the entry which says
"New upstream version"
mentiones features of *all* upstream versions which is not a valid
changelog entry at all. If (at all) a valid entry would have been:
"New upstream bugfix release"
to declare the nature of the upstream change or something like this. We
do not add copies of upstream changes to our packaging changelog - there
is an extra file (see man dh_installchangelogs). If upstream does not
add a changelog file I'd regard it as proper action to create a separate
file debian/changelog.upstream and copy the information to this file.
To make things worse we have in SVN now a completely broken changelog:
tm-align (20050601-1) unstable; urgency=low
^^^^^^^^ this was never released
tm-align (20110124-1) unstable; urgency=low
--> wrong changelog entry as mentioned above
tm-align (20110130-1) unstable; urgency=low
with entry "* Highly efficient debian/changelog."
signed by me - but I never added this entry.
and the Closes entry is missing
tm-align (20110130-2) unstable; urgency=low
is not yet released (at least I did not got any confirmation from
ftpmaster and it contains the Closes phrase.
That's all quite broken and I would like you to fix this please to make
the changelog a real source of information as you requested.
> The issue is strategically important for me because of yet another reason. With an increasing adoption of bio-IT in the drug
> development process, we are likely to see many more tools that are not redistributable for Debian, but that allow for a local
> compilation of the sources. For those tools, and for instance Rosetta is not something that one could too easily ignore, a support
> through Debian would not get any further than to our subversion repository, i.e. the sharing of the debian folder with all the
> build instructions, with its build- and runtime-dependencies. NAMD and VMD are other examples. I do not know for the latter, but
> for Rosetta I know the community support to be excellent, shared between academic groups around the globe. I want those experts to
> consider Debian more for their development and for their sharing through it. Hence, let us experiment with an exchange of package
> build instructions, let us strengthen our Debian Med developer portal's code sharing mechanism and let us accept the
> debian/changelog files as an essential brick towards that.
So back to your point: I could perfectly live with keeping the
pre-release history and your reasoning is perfectly valid to stand
against a potentially angry ftpmaster. So lets iron out this in our
group policy - that's fine. I will try to keep this in mind and will
not strip it of in the future - provided that the entries are correct,
i.e. contain valid IDs are targeting at the correct distribution
(unstable is not a correct distribution for unreleased packages) and do
not contain information which just does not belong into a Debian
> Steffen (who after all this writing has finally decided to upload the sources for his Rosetta package)
Sorry if I tipped on somebodies shoes and please bring the tm-align
changelig in correct shape.