On Tue, Oct 23, 2001 at 09:14:24AM +0200, Matthias Klose wrote:
> Neil Schemenauer writes:
> > Matthias Klose wrote:
> > > - Recommend /usr/bin/env python over /usr/bin/python
> >
> > Again I must express my opposition to this idea. Using /usr/bin/env
> > totally breaks dependencies. There's no
On Tue, Oct 23, 2001 at 01:33:29AM +0200, Matthias Klose wrote:
> 3.1. Version Independant Programs
> -
> Programs that can run with any version of Python must start with
> `#!/usr/bin/env python'. They must also specify a dependency on
> `python-base
Neil Schemenauer writes:
> Matthias Klose wrote:
> > - Recommend /usr/bin/env python over /usr/bin/python
>
> Again I must express my opposition to this idea. Using /usr/bin/env
> totally breaks dependencies. There's no way that I'm going to let
> Debian policy dictate what I can have in my path
Matthias Klose wrote:
> - Recommend /usr/bin/env python over /usr/bin/python
Again I must express my opposition to this idea. Using /usr/bin/env
totally breaks dependencies. There's no way that I'm going to let
Debian policy dictate what I can have in my path.
Neil
Ricardo Javier Cardenes <[EMAIL PROTECTED]> writes:
> I have fixed that, but not uploaded the package while the policy is
> on debate. I suppose this is the case of other maintainers too...
Yep.
Joel
--
Joel Rosdahl <[EMAIL PROTECTED]> (PGP and GPG keys available)
Quoting Matthias Klose <[EMAIL PROTECTED]>:
> Carey Evans writes:
> > Matthias Klose <[EMAIL PROTECTED]> writes:
[...]
> Thanks. Updated in 0.3.2:
>
> http://ftp-master.debian.org/~doko/python/
Nice work updating Neil's policy. I'd be interested to hear Niels comments now
that he is back.
Quoting Matthias Klose <[EMAIL PROTECTED]>:
> Donovan Baarda writes:
> > Good point... I'd forgotten about that. This means we might as well go
> > strait to python2.1 as the default, but make sure that the
> python2.1-xxx
> > packages have versioned conflicts with all the packages that depend on
On Sun, Oct 21, 2001 at 10:58:01PM +1300, Carey Evans wrote:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
>
> (Actually 60, but gimp-python also depends on python-base (<< 1.6.0)).
>
> Packages that depend on python:
>grep-dctrl -FDepends -e 'python([ ,]|$)' Packages
I maintain one of those
Matthias Klose <[EMAIL PROTECTED]> writes:
> Carey Evans writes:
>
> > Another possibility is for python-base to go away, and for a new
> > package that conflicts with it, and has a different name, to take its
> > place.
>
> basically that is Neil's proposal of a python-api package.
I thought p
Donovan Baarda writes:
> Good point... I'd forgotten about that. This means we might as well go
> strait to python2.1 as the default, but make sure that the python2.1-xxx
> packages have versioned conflicts with all the packages that depend on just
> python or python-base and install into /usr/lib/
Carey Evans writes:
> Donovan Baarda <[EMAIL PROTECTED]> writes:
>
> > Good point... I'd forgotten about that. This means we might as well go
> > strait to python2.1 as the default, but make sure that the python2.1-xxx
> > packages have versioned conflicts with all the packages that depend on just
Donovan Baarda writes:
> On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote:
> > Matthias Klose <[EMAIL PROTECTED]> writes:
> >
> > [...]
> >
> > > exactly. But you see that these packages will break when you try to
> > > upgrade. We can't make 2.1 the default right now, because we will
Carey Evans writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > 2.4. Dependencies
> > -
> >
> > Packaged modules must depend on `python-base (> .)' and
> > `python-base (<< .)'.
>
> (>= .), right?
>
> Shouldn't this explain just what . is? I assume i
Donovan Baarda <[EMAIL PROTECTED]> writes:
> Good point... I'd forgotten about that. This means we might as well go
> strait to python2.1 as the default, but make sure that the python2.1-xxx
> packages have versioned conflicts with all the packages that depend on just
> python or python-base and i
On Sun, Oct 21, 2001 at 10:27:54AM +1300, Carey Evans wrote:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> [...]
>
> > exactly. But you see that these packages will break when you try to
> > upgrade. We can't make 2.1 the default right now, because we will
> > _silently_ break packages. Before
Matthias Klose <[EMAIL PROTECTED]> writes:
[...]
> exactly. But you see that these packages will break when you try to
> upgrade. We can't make 2.1 the default right now, because we will
> _silently_ break packages. Before python can point to python2.1, we
> will have to fix all packages which de
Jérôme Marant writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> Hi,
>
> I have some questions about the upgrade procedure:
>
>
> >A. Upgrade Procedure
> >
> >
> > This section describe the procedure for the upgrade from the current
> > `python- (1.5)' packag
Matthias Klose <[EMAIL PROTECTED]> writes:
Hi,
I have some questions about the upgrade procedure:
>A. Upgrade Procedure
>
>
> This section describe the procedure for the upgrade from the current
> `python- (1.5)' packages to the `python1.5-' packages, the
> rem
Matthias Klose <[EMAIL PROTECTED]> writes:
[...]
> 2.4. Dependencies
> -
>
> Packaged modules must depend on `python-base (> .)' and
> `python-base (<< .)'.
(>= .), right?
Shouldn't this explain just what . is? I assume it's actually
., i.e. >=1.5 and <<1.6, >=2.1 an
Neil Schemenauer writes:
> Matthias Klose wrote:
> > At any given time, the package `python-base' should represent the
> > current stable upstream version of Python. XXX: Should we have an
> > exception for the case, when a new upstream version is released during
> > a Debian f
Matthias Klose wrote:
> At any given time, the package `python-base' should represent the
> current stable upstream version of Python. XXX: Should we have an
> exception for the case, when a new upstream version is released during
> a Debian freeze?
It should probably be rewor
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > In my above diagrams the (>=2.1,<2.2) dependancy could be replaced
> with a
> > python-api-2.1 provided by python (as suggested by Neil), but I think
> this
> > actually introduces confusion rather than convenience. The pr
Donovan Baarda <[EMAIL PROTECTED]> writes:
[...]
> IMHO, the best solution given what you have described above is to make each
> new release of python as a "python-X.Y" package that installs
> "/usr/bin/pythonX.Y", and have another small "python" package which depends
> on the latest "python-X.Y"
Donovan Baarda wrote:
> In my above diagrams the (>=2.1,<2.2) dependancy could be replaced with a
> python-api-2.1 provided by python (as suggested by Neil), but I think this
> actually introduces confusion rather than convenience. The problem is that it
> doesn't really represent a particular v
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Jim Penny wrote:
[...]
> The python is a small package to create a link from /usr/bin/python2.2
> to /usr/bin/python. python-eggs is a dummy package for dependencies
> (similar to what is done for GCC). When we upgrade Python to 2.2 we
> have:
>
>
Jim Penny wrote:
> Why? Could you better explain your reasoning here?
> On the face of it, it certainly seems that python-1.5 ought to be
> able to provide python-api-1.5.
It breaks dependencies. We've been through this before but I'll explain
it again. Here's a dependency graph:
On Tue, Oct 02, 2001 at 06:53:39AM -0700, Neil Schemenauer wrote:
> Carey Evans wrote:
> > In my original example, spam embeds libpython2.1.so. It would make
> > sense for this to mean it depends on python-api-2.1, though this isn't
> > what the current shlibs file says.
>
> Only "python" can pro
Carey Evans wrote:
> In my original example, spam embeds libpython2.1.so. It would make
> sense for this to mean it depends on python-api-2.1, though this isn't
> what the current shlibs file says.
Only "python" can provide "python-api-*".
Neil
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> spam should depend on python not python-2.1.
In my original example, spam embeds libpython2.1.so. It would make
sense for this to mean it depends on python-api-2.1, though this isn't
what the current shlibs file says.
--
Carey Evans ht
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > Packages like extension modules _are_ tied to a particular version and
> hence
> > should be in a python-X.Y-foo package that installs into
> /usr/lib/pythonX.Y.
> > There would also be an empty package python-foo that si
Donovan Baarda wrote:
> Packages like extension modules _are_ tied to a particular version and hence
> should be in a python-X.Y-foo package that installs into /usr/lib/pythonX.Y.
> There would also be an empty package python-foo that simply depends on the
> latest python-X.Y-foo and python pack
Carey Evans wrote:
>/> python-2.1 -\
>spam -- > python
>\---> python-eggs ---> python-api-2.1 ---/
spam should depend on python not python-2.1.
Neil
Neil Schemenauer <[EMAIL PROTECTED]> writes:
[...]
> Excellent point. I've updated the policy document to prevent this. The
> python package should provide python-api-X.Y. Module packages should
> depend on python-api-X.Y. If someone packages an older version of
> Python they should call it p
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
[...]
I've done some digging in the archives and found things that look surprisingly
like "my proposal" proposed by others. I don't think the finer points of how it
would work were pinned down though, so I'm going to persist untill someone
tells me
[Please don't CC me, I'm on the list. I wish MUAs would respect the
mail-followup-to header.]
Donovan Baarda wrote:
> From archive updating point of view, my scheme has a large
> python-X.Y-foo added and a small python-foo updated when python
> upgrades. Your scheme has a large python-foo updated
Quoting Neil Schemenauer <[EMAIL PROTECTED]>:
> Donovan Baarda wrote:
> > On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> > > Donovan Baarda wrote:
> > > If you change the major or minor version of Python installed then
> > > packages that depend on it must be upgraded. There
Donovan Baarda wrote:
> On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> > Donovan Baarda wrote:
> > If you change the major or minor version of Python installed then
> > packages that depend on it must be upgraded. There is no way around
> > that.
>
> Yes, but the old packages
On Sat, Sep 29, 2001 at 11:10:43PM -0700, Neil Schemenauer wrote:
> Carey Evans wrote:
> > By way of example, suppose I have a package "spam" that embeds Python
> > 2.1, and therefore depends on python-2.1. spam also uses the "eggs"
> > module, and therefore depends on python-eggs, which depends o
On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> Donovan Baarda wrote:
> > First off, you need to clarify what you are attempting to achieve. There
> > are
> > three possibile aims as I see it;
> >
> > 1) single "official" version of Python in archive/distro.
> > 2) multiple a
Donovan Baarda wrote:
> First off, you need to clarify what you are attempting to achieve. There are
> three possibile aims as I see it;
>
> 1) single "official" version of Python in archive/distro.
> 2) multiple alternative versions of Python in archive/distro, only one
> installed at a time.
>
Carey Evans wrote:
> By way of example, suppose I have a package "spam" that embeds Python
> 2.1, and therefore depends on python-2.1. spam also uses the "eggs"
> module, and therefore depends on python-eggs, which depends on
> python-2.1 itself.
>
> Now Python 2.2 is released, and eggs is recomp
On 18-Sep-2001 Neil Schemenauer wrote:
> Please comment.
>
> Neil
it is /usr/share/common-licenses, not licences. Annoying thing there being two
spellings of some common words.
>
> We could perhaps differenciate python modules and bindings.
>
> For example, libxml bindings for Python would be libxml-python.
> Also, python-gtk would become libgtk-python, python-gnome would become
> libgnome-python
> and so on.
>
> However, xml tools for python would stay pytho
On Wed, 2001-09-26 at 11:37, Jérôme Marant wrote:
> David Coe <[EMAIL PROTECTED]> writes:
>
> > Neil Schemenauer <[EMAIL PROTECTED]> writes:
> >
> > > 2.3. Module Package Names
> > > -
> > >
> > > Python module packages should be named for the primary module
> > >
David Coe <[EMAIL PROTECTED]> writes:
> Neil Schemenauer <[EMAIL PROTECTED]> writes:
>
> > 2.3. Module Package Names
> > -
> >
> > Python module packages should be named for the primary module
> > provided. The naming convention for module `foo' is `python-foo'
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> 2.3. Module Package Names
> -
>
> Python module packages should be named for the primary module
> provided. The naming convention for module `foo' is `python-foo'.
> Packages which include multiple modules may
Neil Schemenauer <[EMAIL PROTECTED]> writes:
> Please comment.
This all looks good. I do have a question concerning dependencies on
Python modules.
By way of example, suppose I have a package "spam" that embeds Python
2.1, and therefore depends on python-2.1. spam also uses the "eggs"
module,
Jim Penny wrote:
> I just want to ask a couple of questions to make sure that I understand
> this in detail. Suppose python2.1 is installed as python and you
> also have python1.5 installed. You have
> script poo which is invoked via #!/usr/bin/python and
> script bah which is invoked via #!/us
On Mon, Sep 17, 2001 at 07:33:26PM -0700, Neil Schemenauer wrote:
>
I just want to ask a couple of questions to make sure that I understand
this in detail. Suppose python2.1 is installed as python and you
also have python1.5 installed. You have
script poo which is invoked via #!/usr/bin/python
Ricardo Javier Cardenes wrote:
> I think this:
>
> /usr/local/lib/python./site-packages
> /usr/local/lib/site-python
> /usr/lib/python./site-packages
>
> should be the order.
I see not problem with that. It shouldn't make any difference except in
the case you describe.
> And what happene
Mikael Hedin wrote:
> Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's
> cosmetics, not really important.
It has been pythonX.Y for many years. We should not change it.
Neil
On Mon, Sep 17, 2001 at 07:33:26PM -0700, Neil Schemenauer wrote:
> 1.2. Module Path
>
>
> Python searches a number of directories for modules. The module
> search path for Debian has been ordered to include these locations at
> the beginning of the path in the fol
Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's
cosmetics, not really important.
--
Mikael Hedin, MSc +46 (0)980 79176
Swedish Institute of Space Physics +46 (0)8 344979 (home)
Box 812, S-981 28 KIRUNA, Sweden+46 (0)70 5891533 (mobile)
[gpg key fingerprint =
53 matches
Mail list logo
