On Saturday 12 November 2011 09:55:39 Kay Hayen wrote: > > I created an ITP for Nuitka here: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648489
I've been following Nuitka, and I think it's great to see how it has progressed over time. Since I've been trying to package Shedskin for Debian, it will be interesting to see how you have approached the packaging exercise. > I have followed your advice in as so far received, and made the > following things: > > a) First of all, I added "setup.py" and distutils stuff to Nuitka, > something I had never done before. For Python packages, I think the benefit of having setup.py outweighs the sometimes bizarre behaviour of distutils. > b) To facilitate that, I have moved the C++ and Assembler codes to new > packages and declared them as package data. That were huge changes, but > for the better I guess. For libraries used only by Shedskin I used /usr/share/shedskin, necessitating patches to the upstream setup.py script. > c) I renamed "Nuitka.py" to a "nuitka" binary. I am keeping the drop-in > replacement as "Python" though. I don't think it's wise to call it "Python", even though virtually everyone using Debian uses case-sensitive filesystems and knows the difference between "python" and "Python". If Nuitka aims to be a Python alternative, shouldn't it use the alternatives mechanism in Debian? > d) I have used "py2dsc -m "Kay Hayen <kayha...@gmx.de>" > Nuitka-0.3.15pre2.tar.gz" on what the dist directory gives me. I have > then edited, the debian directory according to the tutorial. > > e) I have resolved the collision of the binary and package name not by > renaming it, I wouldn't know when and where to do it, but by puting it > into "bin", like this: > > override_dh_auto_install: > python setup.py install --root=debian/nuitka --install-layout=deb > --install-lib=/usr/share/nuitka --install-scripts=/usr/share/nuitka/bin > > override_dh_auto_build: > > and have links like this: > > /usr/share/nuitka/bin/Python /usr/bin/Python > /usr/share/nuitka/bin/nuitka /usr/bin/nuitka > > which appears to work fine. I wonder if there's any benefit to putting things in /usr/share/nuitka/bin, but I suppose you're working within the limitations of distutils. I didn't know there was an --install-layout option to setup.py, but I haven't been following distutils so closely of late. > f) The control file I adapted like this: > > Source: nuitka > Maintainer: Kay Hayen <kayha...@gmx.de> > Section: python > Priority: optional > Build-Depends: python (>= 2.6.6-3), debhelper (>= 7.4.3) > Standards-Version: 3.9.1 > > Package: nuitka > Architecture: all > Depends: ${misc:Depends}, ${python:Depends}, g++-4.6 (>= 4.6.1), scons > (>=2.1.0-1) > Description: Python compiler with full language support and CPython compa > X-Python-Version: >= 2.6 > > The general goal would be to make it back portable, that is why I am > using Python 2.6 as my upstream required minimum. I hope control is the > right spot, the tutorial didn't make that so clear. > > For build depends I am not so sure. I was told to drop X-Python-Version and to put the compilers and build tools into the Recommends field. > ---------- > > Then questions I have: > > 1. The "dch" is not picking up my email address, unlike "reportbug", > kind of annoying. Does it not use the DEBEMAIL environment variable? > 2. I would like to remove the "inline_copy" directory with a patched > scons from the package, as it's not necessary with Debian when having > the dependency. > > 3. My documentation is ".rst", so I guess, i should build-depend on > docutils, and so something, but what? Maybe that's really a distutils > question, but I wonder where to put the resulting pdf. I have python-docutils in my Build-Depends since Shedskin generates a man page from a .rst file. I guess the PDF would live in /usr/share/doc/nuitka, and you could probably mention it in debian/docs. > 4. My workflow now would be to start from py2dsc over and over again, > and to script the replacement of the debian control files. It seems > rather pointless to keep more than those files: > > debian/compat > debian/changelog > debian/rules > debian/control > debian/links > debian/source > debian/source/format > > I will add a copyright file later. I've always worked with the debian directory's files directly, and with recent dh_python developments, the tricky parts like the rules file becomes almost trivial; I have an override in the rules file for the man page: override_dh_auto_clean: rm -f debian/shedskin.1 dh_auto_clean override_dh_auto_build: rst2man doc/shedskin.rst debian/shedskin.1 dh_auto_build The crucial realisation for me was that the changelog and control files really drive the rest of the packaging process. It may seem odd that the changelog has such an important role, but it dictates the version number of the package and whether it is a native or non-native package. > 5. Should I now setup my own repository, or is it realistic to get it > into Debian proper, or is there a lot missing now. The copyright should > be easy for me, but yeah, I have no clue really. > > The package is going to see some flux still, I guess. The "Python" e.g. > should accept options like python does. On the other hand, I have no > clue how to provide an apt repository these days, the HOWTOs I found are > all obsolete, and "repropro" package seems to be more about mirroring. I've been uploading packages to http://mentors.debian.net/ and if you want some kind of quick guide to deploying repositories, take a look at... http://packages.boddie.org.uk/ > 6. The changelog talks of "unstable". Is that OK if I am building > against "testing" ? > > What I have currently, you can browse it at: > > http://www.nuitka.net/volatile/debian/deb_dist/ I was told to build against unstable. For me, this means having a User Mode Linux installation running Debian stable (since I can debootstrap that), and then having a pbuilder instance for unstable inside that (since unstable can't be run on my host system's kernel). Yes, I'm running an old distribution, so it means quite a bit more work. I'd be interested to share notes with you. It would be nice to see some of these Python-related tools get more exposure in Debian. Paul -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201111121508.40025.p...@boddie.org.uk