Re: MglTools packaging (Was: r8804 - trunk/packages/mgltools/pmv/trunk/debian)
On 12/19/2011 09:43 AM, Andreas Tille wrote:
> 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.
>
Your report describes problems with Debian moving. This will get worse
with relying on official releases, not better. The CVS version was
selected because of the incompatibility of version 1.5.4 with python
2.5. Again: the official 1.5.4 release of the mgltools still depends on
python 2.4. They are just shipping it in their binary distribution, so
there is no incompatibility perceived on their end.
Upstream is with Python 2.6 these days with their internal development.
We have already dropped that. And we do not want to create those patches
ourselves but help upstream with it all. Anything else than using the
CVS I can only perceive as unfortunate. And - please do not diss the
packaging. It is an adequate adoption for our distribution and certainly
not "bad". Difficulties we shall resolve with upstream or remove the
packages if the community does not find them useful.
Best,
Steffen
Reply to: