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.