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