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

debian/changelogs, legacy work on packages and other distros


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. 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.

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.


Steffen (who after all this writing has finally decided to upload the sources for his Rosetta package)

Reply to: