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.

Attachment: 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

Reply via email to