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
