[Distutils] [zc.buildout] buildout to .deb package

[Andrew Straw]

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