I use stdeb to build .deb's from Python source distributions. I'm not entirely sure what buildout does, but after letting this screencast play in the background while I work: http://rhodesmill.org/brandon/buildout , I think that I'm accomplishing the same goal using setuptools "develop" command with a "--prefix=" option. I just tested the new stdeb 0.2.3 at the request of Andrew Straw, and it was able to produce a .deb from the allmydata-tahoe source tree. I intend to configure some buildbots to automatically run stdeb to produce .deb's of various of my projects: zfec, pycryptopp, pyutil, etc. Regards, Zooko

Tarek Ziadé wrote:

2009/2/17 Zooko O'Whielacronx :

...

I use stdeb to build .deb's from Python source distributions. I'm not entirely sure what buildout does, but after letting this screencast play in the background while I work: http://rhodesmill.org/brandon/buildout , I think that I'm accomplishing the same goal using setuptools "develop" command with a "--prefix=" option.

I just tested the new stdeb 0.2.3 at the request of Andrew Straw, and it was able to produce a .deb from the allmydata-tahoe source tree. I intend to configure some buildbots to automatically run stdeb to produce .deb's of various of my projects: zfec, pycryptopp, pyutil, etc.

Same remark as bdist_deb : it looks nice to create .deb files for single packages.

I am starting to look at Geoffrey T. Dairiki patch in Distutils, at http://bugs.python.org/issue1054967

Maybe the stdeb team could work on this too ? I'll sen a mail to stdeb maintainer

There is no need to email me separately. I usually lurk here... If you're trying to do package management on Debian, I'd suggest using the Debian system rather than trying to invent your own. (I am reading between the lines here by noting that you are not talking about building debian source packages, but only .debs. Please correct me if that interpretation is wrong.) I personally don't see the point in creating .deb packages without actually generating a .dsc first -- you're just going to avoid Debian machinery that helps make sure your .debs are OK. Furthermore, you have some chance that your .dsc packages will work across debian/ubuntu versions, whereas that chance is much reduced if you're using pure .deb packages. The "benefit" of a straight .deb builder is that it could be incredibly dumb and just build raw archives that get unpacked. I imagine that would bypass Debian policy by unpacking everything in /usr/lib/python2.5/site-packages. (Nowadays, the python-support machinery in Debian unpacks files to /usr/share/pyshared and them symlinks them across acceptable Python versions' site-package directories). Finally, you'll miss out on all the script installation and so on. So, to me, the interesting discussion is not about auto-generation of .debs. It's about auto-generation of .dscs. Those can trivially be turned into .debs, anyway.

I can probably include such a command in Distutils for 2.7 if I get help from Debian specialists

In case the above arguments persue you to reconsider something like bdist_deb in favor of something like sdist_dsc, may I mention that this is already a distutils command installed by stdeb? However, I don't think stdeb is anywhere near ready for inclusion in the stdlib. But I'd welcome help! -Andrew

Tarek Ziadé wrote:

But note that being able to build .deb packages from another system than debian could be a great feature when doable.

Yes, that's true. To produce nice .debs, though you'd have to re-implement a lot of the Debian packaging tools. Probably it's easier just to run a chroot and install them directly. (I guess this suggestion would leave out the Windows users who want to generate .debs.)

...

So, to me, the interesting discussion is not about auto-generation of .debs. It's about auto-generation of .dscs. Those can trivially be turned into .debs, anyway.

Ok. I am clueless here. I need to read some documentation on my side, But if this is comparable to the RPM spec files, it sounds like a good approach.

I know very little about spec files. I understand that they can specify conditional compilation based on the build system. So from one spec file, RHEL 4 might execute different code and have different dependencies than Fedora 10. Debian source packages don't do this -- you have a source package uploaded to the Debian/Ubuntu repository specific for e.g. Lenny or 8.10. The source packages *should* work if all their dependencies are met and transferred to a different system, but you're moving beyond the maintainer's responsibility to care. But, the upshot is that one .dsc file (which is usually cryptographically signed--always for the official repos--and definitely has hash checksums of the original upstream tarball and the debian diffs) specifies one build behavior for one set of dependencies and is typically targeted for one Debian/Ubuntu distribution, but often works on more. I'm more-or-less ignorant on all other aspects of .rpm generation. They really annoyed me with their (lack of) dependency resolution back in the late 90s, but I understand things have improved since then. :)

What about two commands then ?

- sdist_deb (which is a sdist call + the .dsc file generation)

I guess you mean sdist_dsc?

- bdist_deb (which is a sdist_deb call + the creation of the .deb)

That command would be pretty easy, I think ('os.system("dpkg-buildpackage -rfakeroot -uc -b")'). It seems reasonable to do. I personally prefer to keep the .dsc, .orig.tar.gz, and .diff.gz files in case I want to build a binary for a new version of Debian/Ubuntu (altogether the debian source package, which until now I've been abbreviating as .dsc, but that's not quite true). But you knew that already...

...

...

I can probably include such a command in Distutils for 2.7 if I get help from Debian specialists

In case the above arguments persue you to reconsider something like bdist_deb in favor of something like sdist_dsc, may I mention that this is already a distutils command installed by stdeb?

However, I don't think stdeb is anywhere near ready for inclusion in the stdlib. But I'd welcome help!

Well, looking at the sdist_dsc code, it is based on setuptools, so I doubt it could be integrated easily.

True. I don't know how much is critical, and how much that is critical is already in distutils.

That said, I don't think the integration of a new command in Distutils itself, is a huge amount of work, as long as it does one single thing.

If we could work on a simple isolated command that builds the .dsc, then on another command that creates the .deb out of it, it could be the right approach imho.

What do you think ?

Well, there's not really a whole lot to stdeb other than what is needed for the sdist_dsc command. There are two things that I think are requirements before going forward with a proposal to include in distutils: 1) I'm under no illusions about the stdeb code -- it is pretty darn ugly. I wouldn't want to be in the room if it was shown to the python-dev team with a proposal to include in the stdlib in its current state! :) I think a rewrite or major refactoring of stdeb would stand a much better chance of getting in to the stdlib, and would be more maintainable. Unfortunately, I don't have time for that... 2) Sample auto-generated source packages, particularly the debian/rules files, should be critiqued by real Debian developers. Sending them to the debian-python list, for example, would be a reasonable place to start. -Andrew

2009/2/18 zooko :

On Feb 17, 2009, at 15:27 PM, Tarek Ziadé wrote:

...

Same remark as bdist_deb : it looks nice to create .deb files for single packages.

The way that I currently use it is that I run stdeb on each package which is required, and make them all available in an apt repository. > This is certainly the way that Debian/Ubuntu users would expect -- they would object if I produced a single .deb package containing multiple separate Python packages.

I think this might generate another long thread ... :) Zope (my use case with zc.buildout) runs with hundreds of packages. In fact, they all share a few namespaces (zope.*, plone.*) so Zope can be considered as a set of a few "big" packages. When I deploy a customer application, I add some specific packages with the usual set. The set of packages needed to run my customer app is built by zc.buildout, which grabs them at pypi or elswhere, and gather them under the same directory. zc.buildout, besides Python packages, provides some features to generate console scripts and everything around the packages to make an application run. So there's some extra work in there that is not located in any python package. (well it's an application) The scripts generated by buildout hack sys.path so they use the packages gathered by zc.buildout. This mecanism is really useful for us Zope/Plone developers. For example, some packages that are delivered in Zope 2 are now delivered as single python packages (like zope.component, zope.interface and so on). But the problem is : if you have a Zope 2 running on a system, it contains a zope.* code tree that is incompatible with the new components, and having them installed in Python itself will break everything. So basically, one Zope instance is now a directory containing everything needed to run. Making a .deb out of it for me means installing the different parts the buildout is composed of in the right places in the system tree, but also keep the collection of packages in a separated directory, specific to this instance and I would call this directory : my zope application. Regards Tarek