Re: MglTools packaging (Was: r8804 - trunk/packages/mgltools/pmv/trunk/debian)
On Tue, Dec 20, 2011 at 07:40:58PM +0100, Thorsten Alteholz wrote:
> 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.
No. They are just appearing several times for the very same problem.
This is a maintenance nightmare (DRY - Don't Repeat Yourself).
> > 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.
In the case of several packages *my* time is consumed - in the case of
one package the computers time is consumed. If you have trouble with
your hardware you can get access to debian-med.debian.net.
The bugs I linked to have in most cases not triggered any reaction for a
long time - way too long for my taste. For me this is a proof that
something is just wrong.
> > 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!?
The problem is that the uploader (in this and several other cases me
because nobody else cared) is seeking information if get-orig-source
fails. This again costs time. This would not happen if you simple
download the whole release tarball and see: well, this module of the
whole is not part any more which makes immediately clear what to do.
> > 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).
First and most importantly it would be *a* (singular) bug report and not
a series of about ten bug reports. This makes a difference of an order
of magnitude of my own time.
Furthermore Stephen gave wrong facts. The RC2 (same as the CVS tag we
checked out) is not that different from CVS and does not have a
different Python version.
> > 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.
My arguing was targeting at the fact that in the case of moves I would
like to change one package and not ten packages in the very same way.
> 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.
Well, if the packaging is fine the automatic build process is helpfull.
But this argument is void if we receive several bug reporst. These
reports in the first place are a burden we put on other people. I
definitely do not like this. And then we need to change the packaging
10 times to fix the problem. At some point in time this does not
scale.
> > 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.
There was no actual problem with the package. It was simply useless,
confusing and unmaintained - I'd call this reasons enough for removal
but it took time for me to understand that this was actually the case.
And I finally understood this after I inspected the downloadable RC2
tarball...
> > Finally item 7. shows that people
> >become bored about our work which is simply bad.
>
> Yes, we definitely should care about bugs faster.
I repeat: I'm very positive that changing the packaging scheme by
following the upstream file layout closely - be it via direct download
or as a compromise by reimplementing this tarball from CVS (even if
I'm explicitely not convinced to use random CVS checkouts!) does not
matter.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: