Le jeudi 02 octobre 2008 à 10:08 -0700, Toshio Kuratomi a écrit : > So where the concerns intersect is when you go to distribute your > package. To have your package run in as many places as possible, you > want to guarantee the correct versions of libraries are installed in > those places. OTOH, in order to get Linux distributions interested in > packaging your project you really must not use your own private copies > of those libraries. > > (BTW, Josselin seems to be saying something different is true on Debian > but I had posted this question to the cross-distro distributions-list > freedesktop.org two weeks ago after dealing with it in the banshee > package and people seemed to agree that it was not proper packaging. > I'll have to ask for clarification here. Perhaps I phrased my question > poorly on that list :-)
I’m not sure I understand what point you think is different on Debian. We ship several versions of Python at once, but we do not ship several versions of a module unless absolutely necessary. > 1) Have a source tarball that's separate from binary distribution. The > binary distribution can contain the third party modules while the source > tarball just contains your code. Distro packagers will love you for > this because it means the source tarball is clean and they can just g to > work packaging it. Full ACK. Repackaging is a pain. > 4) make sure your package works with vanilla upstream versions of the > third party modules. It's tempting to fix things in your local copies > of modules. If at all possible don't. If that's not possible, make > sure upstream has incorporated the patch and make a note in the README > -- using a patched version of Foo-x.y project. The patch is in their > svn as of DATE. patch is located in myproject/foo-x.y/patches. Doing > this means that the distribution packager of your package can take your > patch to the packager of Foo and ask that the patch be incorporated there. Amen. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig