MglTools packaging (Was: r8804 - trunk/packages/mgltools/pmv/trunk/debian)
On Mon, Dec 19, 2011 at 12:40:58AM +0100, Steffen Möller wrote:
> > I actually very much in favour of building mgltools from plain upstream
> > source as it is provided upstream in one source package and create
> > different source packages. When doing this refactoring a package
> > <name>-common could be created which is needed by more than one binary
> > package. While the packaging of this package is a bit more complex it
> > finally reduces the maintenance effort we had in the past.
>
> I disagree. The build process is mostly automated and works.
> There are more important things to work on. Promised.
My personal experience does not fit this statement.
1. Google: "site:bugs.debian.org mgltools 'depends on python (<< 2.6)'"
Shows a series of bugs which forced our fellow DDs to frist submit
patches and then NMU because nobody from Debian Med did care about
this.
2. Google: "site:bugs.debian.org mgltools 'deprecation of dh_pycentral, please use dh_python2'"
Shows another series of bugs which was not fixed quickly enough
to backup your own claim that we also support Ubuntu (the bug
series was clearly triggered by planed changes in Ubuntu).
3. Google: "site:bugs.debian.org mgltools 'python2.5-dev used as build-dependency, not python-dev or python2.6-dev'"
This series of bugs was quite quickly solved by you
4. Google: "site:bugs.debian.org mgltools 'Please update depends/build-depends from glut3 to freeglut3'"
While only two packages were affected this type of bug was also
not properly handled considering the standard I would like to
apply to Debian Med packages. You refused an offer of NMU
(#543696) and instead asked a NMUer to join our team. The problem
was stalled until the problem became really serios and was fixed
by me.
5. Google: "site:bugs.debian.org mgltools 'Python string exceptions no more allowed in Python 2.6'"
Another (short) series of still open bugs which are forcing us
to fix one problem with several uploads.
6. In bug #651855 we failed to realise that the scenario tool
was just replaced.
7. In bug #605315 somebody even asked for removal of one of the
packages because it seemed unmaintained which was solved in NMU
by aplying a long standing patch.
So why did I spent time in assembling this history of bugs in mgltools?
I wanted to prove that the current way to maintain this tool by not
relying on the released upstream tarball creates a lot of work which is
not only on the back of our shoulders but a lot of other DDs. I'm
personally bored by working on one and the same problem several times
and it is simply error prone to do so. Items 1.-5. above are showing
that the mostly automated process you are claiming above does not work
as expected. Item 6. shows that it does not help in detecting outdated
packages which should be removed. Finally item 7. shows that people
become bored about our work which is simply bad.
My conclusion would be that after the next stable release (which
hopefully comes with a license clarification) we will base our packaging
on the release tarball from upstream and stick to this. Considering the
fact that this packaging is a bit tricky because of the included single
tarballs I'd volunteer to do the necessary research how to do the
packaging properly.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: