2009/2/18 Andrew Straw <straw...@astraw.com>: > > There is no need to email me separately. I usually lurk here...
ok :) > > 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.) yes indeed, But note that being able to build .deb packages from another system than debian could be a great feature when doable. > > 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. 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. What about two commands then ? - sdist_deb (which is a sdist call + the .dsc file generation) - bdist_deb (which is a sdist_deb call + the creation of the .deb) > >> 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. 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 ? Regards Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
