Re: suffix for packages with (optional?) Python extensions
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 them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Cheers,
Julien
--
Julien Cristau julien.cris...@logilab.fr
Logilab http://www.logilab.fr/
Informatique scientifique gestion de connaissances
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120716075759.ga7...@crater1.logilab.fr
Re: suffix for packages with (optional?) Python extensions
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 - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Right now I'd just like to understand what is being proposed.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/063f9746-b6c6-40d9-bbea-637f1ae65...@email.android.com
Re: suffix for packages with (optional?) Python extensions
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
strictly versioned. Probably not a showstopper, but something to be
aware of.
Right now I'd just like to understand what is being proposed.
look at any of mine python-* packages having corresponding -lib package.
e.g.
$ apt-get source python-nipy
...
$ grep -e Package: -e Architecture:
nipy-0.2.0\~rc2+git27-g7b9b5a5/debian/control
Package: python-nipy
Architecture: all
Package: python-nipy-lib
Architecture: any
Package: python-nipy-lib-dbg
Architecture: any
Package: python-nipy-doc
Architecture: all
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120716142418.gy21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
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 package.
all - any package dependencies are often icky, if you want them to be
strictly versioned. Probably not a showstopper, but something to be
aware of.
Right now I'd just like to understand what is being proposed.
look at any of mine python-* packages having corresponding -lib package.
e.g.
$ apt-get source python-nipy
...
$ grep -e Package: -e Architecture:
nipy-0.2.0\~rc2+git27-g7b9b5a5/debian/control Package: python-nipy
Architecture: all
Package: python-nipy-lib
Architecture: any
Package: python-nipy-lib-dbg
Architecture: any
Package: python-nipy-doc
Architecture: all
OK. python-nipy depends on python-nipy-lib. Makes sense.
Package: python-nipy-lib
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
Provides: ${python:Provides}
XB-Python-Version: ${python:Versions}
Description: Analysis of structural and functional neuroimaging data
NiPy is a Python-based framework for the analysis of structural and
functional neuroimaging data.
.
This package provides architecture-dependent builds of the libraries.
Is python-nipy-lib useful on it's own? It seems odd to me that it doesn't at
least Suggest python-nipy.
Scott K
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2045675.bODldYHci7@scott-latitude-e6320
Re: suffix for packages with (optional?) Python extensions
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 disadvantage of such an approach. It seems odd to me that it doesn't at least Suggest python-nipy. and that is where I think circular dependencies are coming -- although I do not remember details and why I haven't had Suggest -- it clearly worth adding -- may be it is ok now ;-) ? -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716150659.gd21...@onerussian.com
Re: suffix for packages with (optional?) Python extensions
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 installed while only extensions are there. That is the only disadvantage of such an approach. It seems odd to me that it doesn't at least Suggest python-nipy. and that is where I think circular dependencies are coming -- although I do not remember details and why I haven't had Suggest -- it clearly worth adding -- may be it is ok now ;-) ? I think it is worth getting consensus on how this should be done before you make a change. 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? Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1347516.j6B7HhzdZl@scott-latitude-e6320
Re: suffix for packages with (optional?) Python extensions
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 unpack/configuration ordering on the package manager. Cheers, Julien -- Julien Cristau julien.cris...@logilab.fr Logilab http://www.logilab.fr/ Informatique scientifique gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716155806.gf7...@crater1.logilab.fr
Re: packaging under SVN and branching (unstable/experimental)
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, e.g.: $ svn ls svn://svn.debian.org/svn/python-modules/packages/python-docutils/branches/ 0.5/ 0.8.1/ ok -- since no other voice was raised -- I would follow the majority of 3 of you: I looked into python-docutils, trunk now tracks the experimental and I guess versioned branches would be dedicated to corresponding fixes to be uploaded to unstable/stable whatever... So I just followed your scheme and postponed any fancy branching -- just progressed the trunk to 0.16-1 uploaded to experimental ;) now will wait for dcommit to finish and will tag it... However, using codenames (e.g. lenny, squeeze, squeeze-backports) seems to be more popular amongst people who are not me. :) when I added branches fetches for my cython's git-svn it found some elderly squeeze branch from Piotr ;) Cheers -- Yaroslav O. Halchenko Postdoctoral Fellow, Department of Psychological and Brain Sciences Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120716161231.gf21...@onerussian.com
