Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Julien Cristau
On Fri, Jul 13, 2012 at 11:57:01 -0400, Scott Kitterman wrote: 1. python{3}-foo which is arch all and follows the current naming convention of foo being the name you import. It would depend on the arch any python-foo- ext package. all - any package dependencies are often icky, if you want

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Scott Kitterman
Julien Cristau julien.cris...@logilab.fr wrote: On Fri, Jul 13, 2012 at 11:57:01 -0400, Scott Kitterman wrote: 1. python{3}-foo which is arch all and follows the current naming convention of foo being the name you import. It would depend on the arch any python-foo- ext package. all -

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Yaroslav Halchenko
On Mon, 16 Jul 2012, Scott Kitterman wrote: 1. python{3}-foo which is arch all and follows the current naming convention of foo being the name you import. It would depend on the arch any python-foo- ext package. all - any package dependencies are often icky, if you want them to be

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Scott Kitterman
On Monday, July 16, 2012 10:24:18 AM Yaroslav Halchenko wrote: On Mon, 16 Jul 2012, Scott Kitterman wrote: 1. python{3}-foo which is arch all and follows the current naming convention of foo being the name you import. It would depend on the arch any python-foo- ext

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Yaroslav Halchenko
On Mon, 16 Jul 2012, Scott Kitterman wrote: OK. python-nipy depends on python-nipy-lib. Makes sense. Is python-nipy-lib useful on it's own? nope -- moreover it might be somewhat detrimental -- module might appear to be installed while only extensions are there. That is the only

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Scott Kitterman
On Monday, July 16, 2012 11:06:59 AM Yaroslav Halchenko wrote: On Mon, 16 Jul 2012, Scott Kitterman wrote: OK. python-nipy depends on python-nipy-lib. Makes sense. Is python-nipy-lib useful on it's own? nope -- moreover it might be somewhat detrimental -- module might appear to be

Re: suffix for packages with (optional?) Python extensions

2012-07-16 Thread Julien Cristau
On Mon, Jul 16, 2012 at 11:37:17 -0400, Scott Kitterman wrote: I think at least suggests, but I think recommends is better if it doesn't behave as a dependency loop. I haven't looked into how this gets handled yet. Anyone? Recommends should be fine AFAIK, since they don't impose any

Re: packaging under SVN and branching (unstable/experimental)

2012-07-16 Thread Yaroslav Halchenko
On Sun, 15 Jul 2012, Jakub Wilk wrote: question: is there any agreement/policy on how to handle (branch naming convention etc) if we are to maintain multiple versions (e.g. for stable/unstable/experimental). Me, myself and I :P all agree that branches should be named after version numbers,