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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig