Re: MglTools packaging (Was: r8804 - trunk/packages/mgltools/pmv/trunk/debian)
On Mon, 19 Dec 2011, Andreas Tille wrote:
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)'"
2. Google: "site:bugs.debian.org mgltools 'deprecation of dh_pycentral, please use dh_python2'"
3. Google: "site:bugs.debian.org mgltools 'python2.5-dev used as build-dependency, not python-dev or python2.6-dev'"
4. Google: "site:bugs.debian.org mgltools 'Please update depends/build-depends from glut3 to freeglut3'"
Ok, but after a first glimpse these problems are not related to the build
process.
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.
On one hand you have the build time of a huge package (which at least on
my hardware is not neglectable). On the other hand you need some time to
handle the debian/-stuff in several packages.
In my oppinion it is easier to handle lots of small tasks.
6. In bug #651855 we failed to realise that the scenario tool
was just replaced.
Hmm, I seem to have missed something here. Was there any problem with
the old scenario package? As far as I remember the package didn't have any
bug!?
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.
Steffen already wrote some words about the python dependency.
After releasing the first tarball and before doing the actual upload of
all mgltools packages, lots of things have been committed to the upstream
repository. In the worst case any commit might have resulted in a
bug-report (okok, I exaggerate).
I'm
personally bored by working on one and the same problem several times
and it is simply error prone to do so.
Yeah, I agree, it is boring.
Items 1.-5. above are showing
that the mostly automated process you are claiming above does not work
as expected.
I am sorry, but I am not sure whether I understand the relation between
those items and the build process itself. As you wrote in another mail
Debian moves on. But this is as well true for Debian Med. If you look at
the weekly build, nowadays almost all packages simply build with
'get-orig-source' and 'svn-buildpackage'. Two fail with a missing numpy
dep (?) and two seem two fail due to an error in the build script itself
(ok, I got something to fix until friday ...). I would say that 20
building packages are not an argument against the build process.
Item 6. shows that it does not help in detecting outdated
packages which should be removed.
At least I became aware of that old package but did not realize that there
is a problem keeping it in the archive.
Finally item 7. shows that people
become bored about our work which is simply bad.
Yes, we definitely should care about bugs faster.
Thorsten
Reply to: