Re: Packaging python-egenix-mx*

[Donovan Baarda]

G'day,

On Sun, Oct 28, 2001 at 10:34:05PM +0100, Joel Rosdahl wrote:
> Hi,
> 
> I have now finished Debianizing eGenix mx BASE (based on patch done by
> Federico Di Gregorio, see bug#56):
> 
> http://www.lemburg.com/files/python/eGenix-mx-Extensions.html
> 
> The upstream maintainer of "the mx packages" (mxdatetime, mxstack,
> mxtools, ...) now distributes everything in one source package, so I
> have used egenix-mx-base as source package name.  It currently builds
> the following binary packages compiled for Python 2.1:
> 
> python-egenix-mxbeebase
> python-egenix-mxdatetime (new version of python-mxdatetime)
> python-egenix-mxproxy
> python-egenix-mxqueue
> python-egenix-mxstack (new version of python-mxstack)
> python-egenix-mxtexttools (new version of python-mxtexttools)
> python-egenix-mxtools (new version of python-mxtools)
> 
> and also
> 
> python-egenix-mx-base-dev
[...]
> 3. As the policy mandates, I have made the packages depend on
> 
>python (>= 2.1), python (<< 2.2)
[...]
> 4. Any other comments?
[...]


My only suggestion is, if you are at all in doubt about supporting multiple
versions of python, don't use the 2.1.1 "support only the default" packaging
option, instead use the 2.1.3-1. "multiple versioned packages" option. 

Note that even if you choose the "multiple versioned packages" option, you
are not required to support all versions, only the default. This allows you
to easily add multiple version support later on if you wish. It actualy
gives you multiple version support for free as you produce new packages,
as each new version doesn't break your old packages.

It might seem like more work initially, but I'm sure in the long run it
will work out easier.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

Re: Final draft of Python Policy (hopefully ;-)

[Donovan Baarda]

G'day, 

Gregor's already answered most of these, but thought I'd throw in a comment
or two.

On Sun, Oct 28, 2001 at 12:11:04AM -0500, Chris Lawrence wrote:
> On Oct 27, Gregor Hoffleit wrote:
> > I've put a version 0.3.6 of the Python Policy Draft on
> > http://people.debian.org/~flight/python/. The version is still a little
> > bit rough and sometimes incomplete, but it already gives a good outline
> > of the Python packaging system we are installing just now.
> > 
> > Please have a look at the document, and post all fundamental problems
> > you have with the content.
> > 
> > If nobody find fundamental show-stoppers that render this unusable,
> > we're going to submit it to Debian Policy very soon.
> 
> My main concern is that the policy seems to force the installation of
> the default version to use anything in the distribution that uses
> python... a few comments, focusing on section 2:

This is not entirely true... it depends on what modules your application
depends on and how the packagers have chosen to package them. If you are
lucky, pythonX.Y- packages (or a version independant 2.1.3/2.
package) for all of them exist, in which case you can choose any version X.Y
for which all the required packages exist. Note that the policy allows you
to create your own pythonX.Y- packages if the existing python-
mantainer chose not to create them.

Note you will have to invoke /usr/bin/pythonX.Y, as without the default
python package installed /usr/bin/python won't exist.

> - If a package works with any version of Python in the archive, is
> there a setup that allows users to choose which version of Python they
> want to have installed?  Or are they stuck with the default version?

I might be confusing things a bit here... do you mean an application
package, or a module package? 

For module packages, users can specify what version to use in their own
scripts with an appropriate "#!/usr/bin/pythonX.Y". For application
packages, the user is bound to whatever version of Python the packager
chose. This can be a particular version using "Depends: pythonX.Y" and
"#!/usr/bin/pythonX.Y", or the default using "Depends: python" and
"#!/usr/bin/python".

Note that a packager _can_ give the end user some degree of control over
what version of python is used by using "#!/usr/bin/env python". This allows
the end user to put whatever they like as python in /usr/local/bin. However,
this is risky as it bypasses all the dependancy checking. I suspect that
package mantainers using this trick will stop after a few bug reports from
people installing beta's in their own /usr/local :-)

> - Should 2.1.1 require python-foo to provide pythonX.Y-foo?

probably a good idea. I can see no reason not to, and allows packages to
depend on pythonX.Y, pythonX.Y-foo so that they can still work when
python and python-foo are upgraded, and a backwards compatible pythonX.Y-foo
released.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Donovan Baarda]

On Sun, Oct 28, 2001 at 02:57:15PM +0100, Jérôme Marant wrote:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> 
> > > 2.1.1 Support Only The Default Version
[...]
> > >   + a new change to the major version of python, will make all
> > > packages depending on the default version being uninstalled, right?
> > > If so, I don't think it is the Right Thing.
> > 
> > s/major//. Correct. Assume we release woody with python (2.1), and we
> 
>   But I don't want all my python packages to be uninstalled because
>   python changed. This is unacceptable.

So choose one of the other alteratives available in the policy :-)

The beauty is there are three different ways of making packages, each with
different benefits and drawbacks.

The "support only the default version" option is IMHO a bad option for most
packages, but some people might like it for their packages. It's biggest
drawback is packages using it _must_ be upgraded when Python upgrades. It's
other drawback is it doesn't automaticly leave you with pythonX.Y-
packages to support older versions of Python. Instead these have to be made
_after_ python- has been fixed to support the new version of Python.

However, people might like using it when they want only one python-
package that will definitely break for a different version of Python. For
people who have a package that meets this criteria, it is better to have the
old packages uninstalled when python changes than to have everything that
uses them mysteriosly stop working.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

Re: Packaging python-egenix-mx*

[Matthias Klose]

Federico Di Gregorio writes:
> On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote:
> > Questions:
> > 
> > 1. Does anyone need Python 1.5 versions of these packages?
> > 
> >Packages I have found that are associated with some of the mx
> >packages are:
> > 
> >python-mysqldb (Suggests: python-mxdatetime)
> >python-popy (Depends: python-mxdatetime)
> >python-psycopg (Depends: python-mxdatetime)
> 
> i plan to drop support for 1.5 from psycopg (at least in debian builds)
> when we'll have a zope for python 2.1 in the archive.
> 
> >python-reportlab (Suggests: python-mxtexttools)
> > 
> >but I currently assume that no one of those will need Python 1.5.
> >Is my assumption incorrect?

I did look at python-mysqldb and python-reportlab. They can use
2.1. I didn't look at python-popy.

> > 2. Should I build Python 2.2 versions of these packages (i.e. will
> >woody include Python 2.2(beta))?

well, woody is not yet frozen, and bug fixes (I read: the final
version) are allowed in a freeze. And woody won't release before
Christmas (the scheduled release date for python2.2).

> > 3. As the policy mandates, I have made the packages depend on
> > 
> >python (>= 2.1), python (<< 2.2)
> > 
> >Lintian doesn't really like that.  :-)  For example:
> > 
> >E: python-egenix-mxdatetime: package-has-a-duplicate-relation python
> >N:
> >N:   The package seems to declare a relation on another package more 
> > than
> >N:   once. This is not only sloppy but can break some tools
> >N:
> > 
> >Okay, this wasn't a question, just a note.

Which tools are this? Basically the error should prevent something like
python (>=1.x), python (>> 1.y).

> > 4. Any other comments?
> > 
> > Oh, and if anyone wants to look at or test the packages, get them
> > here:
> > 
> > deb http://joel.rosdahl.net/debian/ ./
> > deb-src http://joel.rosdahl.net/debian/ ./

looks ok. Would it make sense to add a 'Replaces:' line for those
packages without the '-egenix' part? I.E:

Package: python-egenix-mxdatetime
Replaces: python-mxdatetime


Could you copy these packages to ftp-master.debian.org in
~doko/www/python-uploads?

Thanks, Matthias

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Jérôme Marant writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> > >   But I don't want all my python packages to be uninstalled because
> > >   python changed. This is unacceptable.
> > 
> > So you simply set the new python packages on hold, until all packages
> > you need are converted. What's wrong with this approach?
> 
>   It is wrong because people will have to put their packages on hold: not
>   everyone is familiar with holding packages. 

This will happen in unstable only for a period of one week. You won't
see this in testing. People running unstable should expect some
breakage for a limited time. We minimize the time of unstability be
letting maintainers know when the upgrade will happen. Why the heck do
we have unstable?

>   And if they use daily upgrades or dist-upgrades, they can be surprised
>   to see the packages they are using everyday being removed.
> 
>   This won't happen if the package depends on a precise version of python:
>   the upload of the new python can happen without any problem and the module
>   maintainer will change dependencies on this new python, so modules packages
>   will be smoothly upgraded.

so please explain us how you would do the upgrade. On the current
packages we do have _unversioned_ dependencies.

> > So my propsal would be: make a python1.5-xml package (separate source
> > package), and one of:
> > 
> > - a python-xml package (for 2.1)

pro: package maintainer only needs to support one version. con: you
only support one version.

> > - a python-xml (2.1), a python2.2-xml package
> > - a python-xml (2.1), a python2.1-xml, a python2.2-xml package

basically the same, I would prefer the latter if you think that
python2.1-xml will need to stay if we switch to 2.2.

>   What are the pro and the cons for each one? (except from 2.2 is
>   not out yet)?

>   Could we decide on this through the policy?

No. We could decide that you need at least to provide the package for
the default version ;-) Personally I would like to see basic modules
be provided for each python version available in Debian.

Matthias

Re: Packaging python-egenix-mx*

[Federico Di Gregorio]

On Sun, 2001-10-28 at 22:55, Joel Rosdahl wrote:
> Federico Di Gregorio <[EMAIL PROTECTED]> writes:

> > i plan to drop support for 1.5 from psycopg (at least in debian
> > builds) when we'll have a zope for python 2.1 in the archive.
> 
> Okay.  Will this happen in woody?

i have seen an url to preliminary zope packages in a past mail. i hope
to see both zope and zpsycopgda (with all other zope products) in woody
running on 2.1.

ciao,
federico
 
-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Developer   [EMAIL PROTECTED]
  99.% still isn't 100% but sometimes suffice. -- Me


pgpLhOaCX3Ks7.pgp
Description: PGP signature

Re: Packaging python-egenix-mx*

[Joel Rosdahl]

Federico Di Gregorio <[EMAIL PROTECTED]> writes:

> On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote:
> > python-egenix-mx-base-dev
> 
> note that the location of the header files was wrong in my patch
> (/usr/include/pythonx.y/mx is much better, imho.)

Agreed and changed.

> > 1. Does anyone need Python 1.5 versions of these packages?
> > 
> >Packages I have found that are associated with some of the mx
> >packages are:
> > 
> >python-mysqldb (Suggests: python-mxdatetime)
> >python-popy (Depends: python-mxdatetime)
> >python-psycopg (Depends: python-mxdatetime)
> 
> i plan to drop support for 1.5 from psycopg (at least in debian
> builds) when we'll have a zope for python 2.1 in the archive.

Okay.  Will this happen in woody?

Regards,
Joel

-- 
Joel Rosdahl <[EMAIL PROTECTED]>   (PGP and GPG keys available)

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Carey Evans writes:
> >From Appendix B.2:
> 
> > The new packages will conflict with every Python dependent
> > package, that does depend on `python', `python-base', without
> > depending on `python (<< 1.6)' or `python-base (<< 2.1)'.
> 
> Since the new packages conflict with python-base itself, they don't
> need to conflict with packages that depend on python-base.  I think
> the first `python-base' needs to be removed.

hmm, I should reword this:

  The new packages will conflict with every Python dependent package,
  that does depend on `python', but not on python (<< 1.6) or that
  does depend on python-base.

Re: FYI: Mail to python package maintainers

[Torsten Landschoff]

On Sun, Oct 28, 2001 at 05:33:31PM +0100, Matthias Klose wrote:
 
> Where do we head? We want to upload these new packages to unstable on
> Tuesday (2001-10-30) or Wednesday (2001-10-31). Because most of the
> python dependent packages in Debian have unversioned dependencies on
> the python version, you will have to set the new python packages on
> hold, until you have verified, that they work with the new python version.

Sorry, but I can't understand this sentence. Which new packages will I need 
to set on hold? 

cu
Torsten


pgpAEi85Kypbk.pgp
Description: PGP signature

Re: Packaging python-egenix-mx*

[Federico Di Gregorio]

On Sun, 2001-10-28 at 22:34, Joel Rosdahl wrote:
> Hi,
> 
> I have now finished Debianizing eGenix mx BASE (based on patch done by
> Federico Di Gregorio, see bug#56):
> 
> http://www.lemburg.com/files/python/eGenix-mx-Extensions.html
> 
> The upstream maintainer of "the mx packages" (mxdatetime, mxstack,
> mxtools, ...) now distributes everything in one source package, so I
> have used egenix-mx-base as source package name.  It currently builds
> the following binary packages compiled for Python 2.1:
> 
> python-egenix-mxbeebase
> python-egenix-mxdatetime (new version of python-mxdatetime)
> python-egenix-mxproxy
> python-egenix-mxqueue
> python-egenix-mxstack (new version of python-mxstack)
> python-egenix-mxtexttools (new version of python-mxtexttools)
> python-egenix-mxtools (new version of python-mxtools)
> 
> and also
> 
> python-egenix-mx-base-dev

note that the location of the header files was wrong in my patch
(/usr/include/pythonx.y/mx is much better, imho.)

> 
> which includes headers for the C API to the libraries.
> 
> Questions:
> 
> 1. Does anyone need Python 1.5 versions of these packages?
> 
>Packages I have found that are associated with some of the mx
>packages are:
> 
>python-mysqldb (Suggests: python-mxdatetime)
>python-popy (Depends: python-mxdatetime)
>python-psycopg (Depends: python-mxdatetime)

i plan to drop support for 1.5 from psycopg (at least in debian builds)
when we'll have a zope for python 2.1 in the archive.

>python-reportlab (Suggests: python-mxtexttools)
> 
>but I currently assume that no one of those will need Python 1.5.
>Is my assumption incorrect?
> 
> 2. Should I build Python 2.2 versions of these packages (i.e. will
>woody include Python 2.2(beta))?
> 
> 3. As the policy mandates, I have made the packages depend on
> 
>python (>= 2.1), python (<< 2.2)
> 
>Lintian doesn't really like that.  :-)  For example:
> 
>E: python-egenix-mxdatetime: package-has-a-duplicate-relation python
>N:
>N:   The package seems to declare a relation on another package more 
> than
>N:   once. This is not only sloppy but can break some tools
>N:
> 
>Okay, this wasn't a question, just a note.
> 
> 4. Any other comments?
> 
> Oh, and if anyone wants to look at or test the packages, get them
> here:
> 
> deb http://joel.rosdahl.net/debian/ ./
> deb-src http://joel.rosdahl.net/debian/ ./

thank you very much!

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact[EMAIL PROTECTED]
INIT.D Developer   [EMAIL PROTECTED]
 Best friends are often failed lovers. -- Me


pgptZeBWtS8D9.pgp
Description: PGP signature

Packaging python-egenix-mx*

[Joel Rosdahl]

Hi,

I have now finished Debianizing eGenix mx BASE (based on patch done by
Federico Di Gregorio, see bug#56):

http://www.lemburg.com/files/python/eGenix-mx-Extensions.html

The upstream maintainer of "the mx packages" (mxdatetime, mxstack,
mxtools, ...) now distributes everything in one source package, so I
have used egenix-mx-base as source package name.  It currently builds
the following binary packages compiled for Python 2.1:

python-egenix-mxbeebase
python-egenix-mxdatetime (new version of python-mxdatetime)
python-egenix-mxproxy
python-egenix-mxqueue
python-egenix-mxstack (new version of python-mxstack)
python-egenix-mxtexttools (new version of python-mxtexttools)
python-egenix-mxtools (new version of python-mxtools)

and also

python-egenix-mx-base-dev

which includes headers for the C API to the libraries.

Questions:

1. Does anyone need Python 1.5 versions of these packages?

   Packages I have found that are associated with some of the mx
   packages are:

   python-mysqldb (Suggests: python-mxdatetime)
   python-popy (Depends: python-mxdatetime)
   python-psycopg (Depends: python-mxdatetime)
   python-reportlab (Suggests: python-mxtexttools)

   but I currently assume that no one of those will need Python 1.5.
   Is my assumption incorrect?

2. Should I build Python 2.2 versions of these packages (i.e. will
   woody include Python 2.2(beta))?

3. As the policy mandates, I have made the packages depend on

   python (>= 2.1), python (<< 2.2)

   Lintian doesn't really like that.  :-)  For example:

   E: python-egenix-mxdatetime: package-has-a-duplicate-relation python
   N:
   N:   The package seems to declare a relation on another package more than
   N:   once. This is not only sloppy but can break some tools
   N:

   Okay, this wasn't a question, just a note.

4. Any other comments?

Oh, and if anyone wants to look at or test the packages, get them
here:

deb http://joel.rosdahl.net/debian/ ./
deb-src http://joel.rosdahl.net/debian/ ./

Regards,
Joel

-- 
Joel Rosdahl <[EMAIL PROTECTED]>   (PGP and GPG keys available)

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Jérôme Marant]

Matthias Klose <[EMAIL PROTECTED]> writes:

 
> It already exists:
> 
>   deb http://ftp-master.debian.org/~doko/python ./ 

  So, it will exist soon.

> 
> > > s/major//. Correct. Assume we release woody with python (2.1), and we
> > 
> >   But I don't want all my python packages to be uninstalled because
> >   python changed. This is unacceptable.
> 
> So you simply set the new python packages on hold, until all packages
> you need are converted. What's wrong with this approach?

  It is wrong because people will have to put their packages on hold: not
  everyone is familiar with holding packages. 
  And if they use daily upgrades or dist-upgrades, they can be surprised
  to see the packages they are using everyday being removed.

  This won't happen if the package depends on a precise version of python:
  the upload of the new python can happen without any problem and the module
  maintainer will change dependencies on this new python, so modules packages
  will be smoothly upgraded.

> So my propsal would be: make a python1.5-xml package (separate source
> package), and one of:
> 
> - a python-xml package (for 2.1)
> - a python-xml (2.1), a python2.2-xml package
> - a python-xml (2.1), a python2.1-xml, a python2.2-xml package

  What are the pro and the cons for each one? (except from 2.2 is not out yet)?
  Could we decide on this through the policy?

  Thanks.

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

http://marant.org

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Carey Evans]

>From Appendix B.2:

> The new packages will conflict with every Python dependent
> package, that does depend on `python', `python-base', without
> depending on `python (<< 1.6)' or `python-base (<< 2.1)'.

Since the new packages conflict with python-base itself, they don't
need to conflict with packages that depend on python-base.  I think
the first `python-base' needs to be removed.

-- 
 Carey Evans  http://home.clear.net.nz/pages/c.evans/

  "Ha ha!  Puny receptacle!"

FYI: Mail to python package maintainers

[Matthias Klose]

I sent the following mail "Python-2.1 becoming Debian's default Python
^version" to each maintainer probably affected by the switch to the new
Python version:


You get this mail, because you are the maintainer of packages probably
affected by the change of the Python version. Followups and replies,
which could be of interest for all "Python packagers", should be sent to
[EMAIL PROTECTED] Your packages are:

  

What happened? In the past months, we had several discussions about
different versions of Python in Debian, and how to make upgrades between
different versions. You can read it in the archives of the debian-python
mailing list (http://lists.debian.org/debian-python/2001/).

The discussions led to a proposed python policy. The current version
0.3.7 can be found at

  http://ftp-master.debian.org/~doko/python/python-policy.txt

Newer versions may exist at http://people.debian.org/~flight/python/.

We prepared python packages, which follow this policy and which make
Python 2.1 the default Python version in Debian. These packages can be
found at:

  deb http://ftp-master.debian.org/~doko/python ./


Where do we head? We want to upload these new packages to unstable on
Tuesday (2001-10-30) or Wednesday (2001-10-31). Because most of the
python dependent packages in Debian have unversioned dependencies on
the python version, you will have to set the new python packages on
hold, until you have verified, that they work with the new python version.

If it is necessary to ship the next Debian release with python1.5, we
will do. We will not ship with the python2.0 packages, as all these
packages cn be converted to use version 2.1. There are 2.2 beta packages
in unstable, but not as the default, because the final 2.2 version
is not yet released.

What changed with the new packages?

- The python-base package is gone. We have no package providing
  python-base, because we simply do not know, if a package is compatible
  with version 2.1. So for the simplest case, a package maintainer
  should check, if his package works with 2.1, and then replace the
  dependency on python-base with:

Depends: python (>= 2.1), python (<< 2.2).

  If the package does not work with the new version, the package should
  depend on python1.5 and scripts must call the interpreter 'python1.5'
  explicitely.

  This will lead to a short period of instability in unstable, but
  should be resolveable within a week.

- See the Appendix B of the python-policy for an upgrade path.


Need some help? We will prepare NMUs for packages, which are maintained by
the Debian-QA team. If I am asked for and my time allows it, I am willing
to make NMUs for other packages as well (or better: directly ask on
debian-python@lists.debian.org).

If you want to build packages for the new schema, there is a group
writeable directory on ftp.master.debian.org: ~doko/www/python-uploads,
where you could place your newly built packages. I will copy these
packages to incoming together with the new Python packages.

We hope to make a smooth upgrade from 1.5 to 2.1 and provide a current
Python version with bells, whistles and packages for woody.

Matthias Klose (and Gregor Hoffleit).

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Anthony Towns]

On Sun, Oct 28, 2001 at 03:43:13PM +0100, Matthias Klose wrote:
> python-xml and python-newt are the only modules, that some base
> packages depend on (boot-floppies and reportbug). 

These are both "standard" not "base" for reference, so there's no freeze
worries for them yet.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

 "Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it.
   C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who
can't deal with deconstructionist humor. Code Blue."
-- Mike Hoye,
  see http://azure.humbug.org.au/~aj/armadillos.txt

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Jérôme Marant writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> 
> > > 2.1.1 Support Only The Default Version
> > > 
> > >   + does this "Depends: python (>= X.Y), python (<< X.Y+1)" really
> > > work since versioned provides do not exist yet? Isn't it
> > > python-base rather than python ?
> > 
> > yes. python is a real package now. It is a replacement for python-base
> > (but it conflicts with python-base).
> 
>   What does a real package mean for you? I've looked through the whole
>   package list and I didn't find any "python" package.
>   "python" is currently a virtual package provided by python-base.
>   So I don't understand how version comparisons can work without
>   versioned provides.
> 
>   Or maybe is it something planned?

It already exists:

deb http://ftp-master.debian.org/~doko/python ./ 

> > s/major//. Correct. Assume we release woody with python (2.1), and we
> 
>   But I don't want all my python packages to be uninstalled because
>   python changed. This is unacceptable.

So you simply set the new python packages on hold, until all packages
you need are converted. What's wrong with this approach?

> > release woody+1 with python (2.4). Then we have to make sure, that a
> > dist-upgrade doesn't break anything. That's doable. Now we replace
> > python (2.1) with python (2.3) in unstable. You see, that the new
> > version breaks the old one. But only as long as the packages are
> 
>   The problematic thing here is programs containing "#!/usr/bin/env python".

There's nothing problematic. See 3./3.2 of the policy.

> > upgraded to use the new version as well.
> > 
> > >   + I think that "Depends: python." would work better and avoid
> > > breaking things.
> > 
> > Using python-foo with the new python version would be still broken.
> > Basically your proposal is 2.1.2.
> 
>   Yes it is. But if you upload a new version of Python as "python",
>   nothing will be broken. I would say that "python" is fine for
>   those using apt-get install python but I still doubt that it is
>   a good thing to use it in dependencies.

sorry, I don't understand this argument.

> > >+ I don't see the need for a "default package python-" there
> > >  What for is it meant to be used?
> > 
> > It let's a package depend on:
> > 
> >python (>= 2.1), python (<< 2.2), python-foo
> > 
> > and can expect a working default Python version, which has support for
> > python-foo.
> 
>   Yes, it is fine for the user as I said previously.
> 
> ...
> > > python-xml
> > > Depends: python (>= 2.1), python (<< 2.2), python2.1-module
> > 
> > s/module/xml/;  s/python2.1-base/python2.1/
> ...
> > > Have all these packages to be built with the same source?
> > 
> > No. Although it avoids source code duplication, it makes it more
> > difficult to remove an older version. My proposal would be to build
> > 1.5 and 2.0 packages from one source and 2.1 and 2.2 packages from
> > another source package, so the first source package and binary
> > packages can easily be removed.
> 
>   We do not support 2.0 any more, BTW.

we proposed not to support 2.0 anymore, yes.

>   What about python-xml? Does it have to be build with python2.1-xml
>   and generally always with the newest python version of the package?

python-xml and python-newt are the only modules, that some base
packages depend on (boot-floppies and reportbug). So IMO we need to
have at least packages python1.5-xml and python1.5-newt (NMU
prepared). 'base' is already frozen, so we should not force an upgrade
to 2.1 for these packages (if we see, that the packages work, we can
depend them on 2.1 later).

So my propsal would be: make a python1.5-xml package (separate source
package), and one of:

- a python-xml package (for 2.1)
- a python-xml (2.1), a python2.2-xml package
- a python-xml (2.1), a python2.1-xml, a python2.2-xml package

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Jérôme Marant]

Gregor Hoffleit <[EMAIL PROTECTED]> writes:

> If nobody find fundamental show-stoppers that render this unusable,
> we're going to submit it to Debian Policy very soon.

  I think we could also add a section about how to use distutils
  to install things in the right place.

  My 2 eurocents,

  Cheers,

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

http://marant.org

Re: Final draft of Python Policy (hopefully ;-)

[Jérôme Marant]

Matthias Klose <[EMAIL PROTECTED]> writes:

 
> s/python-base/python/.

  I would prefer to keep "python-base" because it reflects that it does
  not contain the whole python distribution but rather the basic modules.
 
> > - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good
> > name... maybe /usr/share/python/site-packages instead.  (After all,
> > the things should be arch independent.)  I'd be happy to code up the
> > symlink thingamajig for 2.1.2.2 if nobody's working on it.
> 
> And what about binary dependent site packages?

  I previously propose to install binary indep. files in /usr/share/pythonX.Y
  and binary dep. files is /usr/lib/pythonX.Y.

  I proposed to change sys.path this way:

  /usr/local/lib/python./site-packages
  /usr/local/share/python./site-packages
  /usr/lib/python./site-packages
  /usr/share/python./site-packages

  (there are probably some missing items, but this is the main idea)

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

http://marant.org

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Jérôme Marant]

Matthias Klose <[EMAIL PROTECTED]> writes:

> > 2.1.1 Support Only The Default Version
> > 
> >   + does this "Depends: python (>= X.Y), python (<< X.Y+1)" really
> > work since versioned provides do not exist yet? Isn't it
> > python-base rather than python ?
> 
> yes. python is a real package now. It is a replacement for python-base
> (but it conflicts with python-base).

  What does a real package mean for you? I've looked through the whole
  package list and I didn't find any "python" package.
  "python" is currently a virtual package provided by python-base.
  So I don't understand how version comparisons can work without
  versioned provides.

  Or maybe is it something planned?

> 
> >   + a new change to the major version of python, will make all
> > packages depending on the default version being uninstalled, right?
> > If so, I don't think it is the Right Thing.
> 
> s/major//. Correct. Assume we release woody with python (2.1), and we

  But I don't want all my python packages to be uninstalled because
  python changed. This is unacceptable.

> release woody+1 with python (2.4). Then we have to make sure, that a
> dist-upgrade doesn't break anything. That's doable. Now we replace
> python (2.1) with python (2.3) in unstable. You see, that the new
> version breaks the old one. But only as long as the packages are

  The problematic thing here is programs containing "#!/usr/bin/env python".

> upgraded to use the new version as well.
> 
> >   + I think that "Depends: python." would work better and avoid
> > breaking things.
> 
> Using python-foo with the new python version would be still broken.
> Basically your proposal is 2.1.2.

  Yes it is. But if you upload a new version of Python as "python",
  nothing will be broken. I would say that "python" is fine for
  those using apt-get install python but I still doubt that it is
  a good thing to use it in dependencies.

> >+ I don't see the need for a "default package python-" there
> >  What for is it meant to be used?
> 
> It let's a package depend on:
> 
>python (>= 2.1), python (<< 2.2), python-foo
> 
> and can expect a working default Python version, which has support for
> python-foo.

  Yes, it is fine for the user as I said previously.

...
> > python-xml
> > Depends: python (>= 2.1), python (<< 2.2), python2.1-module
> 
> s/module/xml/;  s/python2.1-base/python2.1/
...
> > Have all these packages to be built with the same source?
> 
> No. Although it avoids source code duplication, it makes it more
> difficult to remove an older version. My proposal would be to build
> 1.5 and 2.0 packages from one source and 2.1 and 2.2 packages from
> another source package, so the first source package and binary
> packages can easily be removed.

  We do not support 2.0 any more, BTW.

  What about python-xml? Does it have to be build with python2.1-xml
  and generally always with the newest python version of the package?

  Thanks. 

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

http://marant.org

Re: Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Chris Lawrence writes:
> - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good
> name... maybe /usr/share/python/site-packages instead.  (After all,
> the things should be arch independent.)  I'd be happy to code up the
> symlink thingamajig for 2.1.2.2 if nobody's working on it.

See 1.4: It's still in sys.path, but it's use is deprecated.

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Joel Rosdahl writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> 
> > It let's a package depend on:
> > 
> >python (>= 2.1), python (<< 2.2), python-foo
> > 
> > and can expect a working default Python version, which has support for
> > python-foo.
> 
> You mean
> 
> python, python-foo
> 
> I presume?

You may want to do this, if you _know_ that your packages work with
python2.4 and python3 as well.

> > My proposal would be to build 1.5 and 2.0 packages from one source
> > and 2.1 and 2.2 packages from another source package, so the first
> > source package and binary packages can easily be removed.
> 
> Why is this easier or better than uploading a new version of the
> source package that just builds 2.1 and 2.2 packages?

If you support 2.1 and 2.2 only, yes, then it's easiser :)

Matthias

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Joel Rosdahl]

Matthias Klose <[EMAIL PROTECTED]> writes:

> It let's a package depend on:
> 
>python (>= 2.1), python (<< 2.2), python-foo
> 
> and can expect a working default Python version, which has support for
> python-foo.

You mean

python, python-foo

I presume?

> My proposal would be to build 1.5 and 2.0 packages from one source
> and 2.1 and 2.2 packages from another source package, so the first
> source package and binary packages can easily be removed.

Why is this easier or better than uploading a new version of the
source package that just builds 2.1 and 2.2 packages?

Joel

-- 
Joel Rosdahl <[EMAIL PROTECTED]>   (PGP and GPG keys available)

Re: Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Chris Lawrence writes:
> On Oct 27, Gregor Hoffleit wrote:
> > I've put a version 0.3.6 of the Python Policy Draft on
> > http://people.debian.org/~flight/python/. The version is still a little
> > bit rough and sometimes incomplete, but it already gives a good outline
> > of the Python packaging system we are installing just now.
> > 
> > Please have a look at the document, and post all fundamental problems
> > you have with the content.
> > 
> > If nobody find fundamental show-stoppers that render this unusable,
> > we're going to submit it to Debian Policy very soon.
> 
> My main concern is that the policy seems to force the installation of
> the default version to use anything in the distribution that uses
> python... a few comments, focusing on section 2:

Partly. You have to install the default version. You are free to
install any other Python version. A package is allowed to use these
other versions (although we would like to see it to use the default
version).

> - If a package works with any version of Python in the archive, is
> there a setup that allows users to choose which version of Python they
> want to have installed?  Or are they stuck with the default version?

They are "stuck" with the default version. If you want to experiment
how your package works with different versions, use dpkg-divert.

Please remember: Debian is not a "Distribution for Python Development
and Porting supporting multiple versions of Python".

> - If not, how is /usr/bin/python going to be handled?  We threw out
> using an alternative for it, but that was when we were still calling
> the default version "python-base".  If the default version isn't
> installed, presumably /usr/bin/python doesn't exist under the current
> setup.  What do you use for a #! then?

s/python-base/python/.

/usr/bin/python is in the `python' package. Interesting question not
to install the default version, but another question: Then you cannot
rely on /usr/bin/python beeing existent. But then your package should
use pythonX.Y for the interpreter name anyway.

> - Why is the following statement in the policy (2.1.1)?
> 
> "You should not make a default, unversioned module package python-foo
> depend on the versioned Python package pythonX.Y!"
> 
> 'Depends: pythonX.Y' appears to be synonymous to
> 'Depends: python (>= X.Y), python (<< X.Y+1)'.  Is this some sort of
> newbie-friendliness we're going for?  If so, why?

assume, we have python (1.5) (providing the python link), and package
python-foo depending on python1.5. python-foo calls the python
interpreter with '#! python'. Noe we upgrade to python
(2.1). python-foo still depends on python1.5, but the python1.5
interpreter is available under the name python1.5. So your package may
break. On the other hand, depending on python (>= X.Y), python (<< X.Y+1)
breaks your package intentionally. So a package maintainer has to
acknowledge the package works with the new version and upgrade the
dependency.

If you do have such a trivial application, which doesn't install
python modules and doesn't rely on version specifics, you still can
depend on python (>= some-version).

> - Should 2.1.1 require python-foo to provide pythonX.Y-foo?

Interesting. Yes, that would make package names more orthogonal. Are
we allowed to add all these virtual packages according to the Debian
policy?

> - Again in 2.1.1: Should any new python-foo conflict with python-base
> (<= 1.5.2-18.4) so python-base has to be upgraded for python-foo to be
> upgraded too?  (Could this get rid of the whole conficts problem in
> python core?)

See my 18.6 packages at

deb http://ftp-master.debian.org/~doko/python ./

pyhton-base becomes python, the new package conflicts with
python-base.

> - Would it be cleaner to make all pythonX.Y-foo provide python-foo, so
> any version-independent package that needs foo can depend on
> python-foo?  If we did this (and got rid of the Depends funkiness) we
> could throw out 2.1.1 completely, as it would be a special case of
> 2.1.2.

No. Assume you install python1.5-foo providing python-foo and
python2.1-bar providing python-bar. A package depending on python-foo
and -bar won't work.

> - 2.1.2.2, or some other part of the policy, should explicitly
> prohibit the use of /usr/lib/site-python, as it is deprecated
> upstream.

I'l add it.

> - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good
> name... maybe /usr/share/python/site-packages instead.  (After all,
> the things should be arch independent.)  I'd be happy to code up the
> symlink thingamajig for 2.1.2.2 if nobody's working on it.

And what about binary dependent site packages?

I am not sure, why Gregor re-added /usr/lib/site-python ...

Anyway, Gregor wanted to discuss the move to /usr/share with upstream,
before we are going to provide it in the Debian packages. We should
add a section 'Open Issues' at the end...

> - Perhaps instead of a dependency on python (<= X.Y+1), 2.1.2.2 should
> say packages should confic

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Matthias Klose]

Jérôme Marant writes:
> Gregor Hoffleit <[EMAIL PROTECTED]> writes:
> 
> > I've put a version 0.3.6 of the Python Policy Draft on
> > http://people.debian.org/~flight/python/. The version is still a little
> > bit rough and sometimes incomplete, but it already gives a good outline
> > of the Python packaging system we are installing just now.
> > 
> > Please have a look at the document, and post all fundamental problems
> > you have with the content.
> 
>   I've asked some questions to Matthias in private yesterday because I
>   didn't have enough time to follow all recent threads and question.
>   So, some of the questions may have already been asked.

[didn't read my mail yesterday ...]

> 2.1.1 Support Only The Default Version
> 
>   + does this "Depends: python (>= X.Y), python (<< X.Y+1)" really
> work since versioned provides do not exist yet? Isn't it
> python-base rather than python ?

yes. python is a real package now. It is a replacement for python-base
(but it conflicts with python-base).

>   + a new change to the major version of python, will make all
> packages depending on the default version being uninstalled, right?
> If so, I don't think it is the Right Thing.

s/major//. Correct. Assume we release woody with python (2.1), and we
release woody+1 with python (2.4). Then we have to make sure, that a
dist-upgrade doesn't break anything. That's doable. Now we replace
python (2.1) with python (2.3) in unstable. You see, that the new
version breaks the old one. But only as long as the packages are
upgraded to use the new version as well.

>   + I think that "Depends: python." would work better and avoid
> breaking things.

Using python-foo with the new python version would be still broken.
Basically your proposal is 2.1.2.

>   + Do we really need to use python-base and al. packages except for
> the transtion?
> 
> Or maybe for python version independent modules?
> 
>   + Mainly I don't see the reason for this "support for default version"
> case.

In the ideal case, we ship a Debian release with one Python version
(the default). We may have to support older/new python versions for
packages requiring these Python versions.

> 2.1.3
> 
>1. 
> 
>+ Is pythonX.Y-module the same thing as python-api defined by Neil?

should be pythonX.Y-foo. Changed.

>+ I don't see the need for a "default package python-" there
>  What for is it meant to be used?

It let's a package depend on:

   python (>= 2.1), python (<< 2.2), python-foo

and can expect a working default Python version, which has support for
python-foo.

> Now, the concrete case of python-xml. If I also want to ship a
> version for 1.5.  If I undestood correctly the document, I'll have
> this :
> 
> -=-=-=-=-=-=-=
> 
> python2.1-xml
> Depends: libc6 (>= 2.2.3-7), python2.1-base, python2.1-xmlbase
> 
> python-xml
> Depends: python (>= 2.1), python (<< 2.2), python2.1-module

s/module/xml/;  s/python2.1-base/python2.1/

> [I guess that some dependancies are missing there, but i'm following the
>  document.
>  Maybe adding python2.1-xml?
> 
> ]
> 
> python1.5-xml
> Depends: libc6 (>= 2.2.3-7), python1.5-base

s/python1.5-base/python1.5/

> -=-=-=-=-=-=-

So basically these are the correct dependencies.

> Have all these packages to be built with the same source?

No. Although it avoids source code duplication, it makes it more
difficult to remove an older version. My proposal would be to build
1.5 and 2.0 packages from one source and 2.1 and 2.2 packages from
another source package, so the first source package and binary
packages can easily be removed.

>   I think that we should include a section about maintainers scripts
>   for python modules.

Ok. I will add one (with the example scripts in the appendix).

Re: Final draft of Python Policy (hopefully ;-)

[Donovan Baarda]

On Sat, Oct 27, 2001 at 01:38:05AM +0200, Gregor Hoffleit wrote:
> I've put a version 0.3.6 of the Python Policy Draft on
> http://people.debian.org/~flight/python/. The version is still a little
> bit rough and sometimes incomplete, but it already gives a good outline
> of the Python packaging system we are installing just now.
> 
> Please have a look at the document, and post all fundamental problems
> you have with the content.
> 
> If nobody find fundamental show-stoppers that render this unusable,
> we're going to submit it to Debian Policy very soon.


Looks good! Nice work all, particularly Neil, Matthias, and Gregor. Thank
you all for making a solid policy, and most of all, the packages to go with
it. I owe you all big time, and if there's ever anything you'd like me to
do, don't hesitate to ask :-)

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

Re: (2nd try) Final draft of Python Policy (hopefully ;-)

[Jérôme Marant]

Gregor Hoffleit <[EMAIL PROTECTED]> writes:

> I've put a version 0.3.6 of the Python Policy Draft on
> http://people.debian.org/~flight/python/. The version is still a little
> bit rough and sometimes incomplete, but it already gives a good outline
> of the Python packaging system we are installing just now.
> 
> Please have a look at the document, and post all fundamental problems
> you have with the content.

  I've asked some questions to Matthias in private yesterday because I
  didn't have enough time to follow all recent threads and question.
  So, some of the questions may have already been asked.

2.1.1 Support Only The Default Version

  + does this "Depends: python (>= X.Y), python (<< X.Y+1)" really
work since versioned provides do not exist yet? Isn't it
python-base rather than python ?

  + a new change to the major version of python, will make all
packages depending on the default version being uninstalled, right?
If so, I don't think it is the Right Thing.
 
  + I think that "Depends: python." would work better and avoid
breaking things.

  + Do we really need to use python-base and al. packages except for
the transtion?

Or maybe for python version independent modules?

  + Mainly I don't see the reason for this "support for default version"
case.

2.1.3

   1. 

   + Is pythonX.Y-module the same thing as python-api defined by Neil?

   + I don't see the need for a "default package python-" there
 What for is it meant to be used?


Now, the concrete case of python-xml. If I also want to ship a version for 1.5.
If I undestood correctly the document, I'll have this :

-=-=-=-=-=-=-=

python2.1-xml
Depends: libc6 (>= 2.2.3-7), python2.1-base, python2.1-xmlbase

python-xml
Depends: python (>= 2.1), python (<< 2.2), python2.1-module

[I guess that some dependancies are missing there, but i'm following the
 document.
 Maybe adding python2.1-xml?

]

python1.5-xml
Depends: libc6 (>= 2.2.3-7), python1.5-base

-=-=-=-=-=-=-

Have all these packages to be built with the same source?


> 
> If nobody find fundamental show-stoppers that render this unusable,
> we're going to submit it to Debian Policy very soon.

  I think that we should include a section about maintainers scripts
  for python modules.


Thanks.

-- 
Jérôme Marant <[EMAIL PROTECTED]>
  <[EMAIL PROTECTED]>

http://marant.org

Re: Final draft of Python Policy (hopefully ;-)

[Chris Lawrence]

On Oct 27, Gregor Hoffleit wrote:
> I've put a version 0.3.6 of the Python Policy Draft on
> http://people.debian.org/~flight/python/. The version is still a little
> bit rough and sometimes incomplete, but it already gives a good outline
> of the Python packaging system we are installing just now.
> 
> Please have a look at the document, and post all fundamental problems
> you have with the content.
> 
> If nobody find fundamental show-stoppers that render this unusable,
> we're going to submit it to Debian Policy very soon.

My main concern is that the policy seems to force the installation of
the default version to use anything in the distribution that uses
python... a few comments, focusing on section 2:

- If a package works with any version of Python in the archive, is
there a setup that allows users to choose which version of Python they
want to have installed?  Or are they stuck with the default version?

- If not, how is /usr/bin/python going to be handled?  We threw out
using an alternative for it, but that was when we were still calling
the default version "python-base".  If the default version isn't
installed, presumably /usr/bin/python doesn't exist under the current
setup.  What do you use for a #! then?

- Why is the following statement in the policy (2.1.1)?

"You should not make a default, unversioned module package python-foo
depend on the versioned Python package pythonX.Y!"

'Depends: pythonX.Y' appears to be synonymous to
'Depends: python (>= X.Y), python (<< X.Y+1)'.  Is this some sort of
newbie-friendliness we're going for?  If so, why?

The only "good reason" I can think of is to have a parallel between
the python-foo/python and pythonM.N-foo/pythonM.N names.  But since
that's rather user-invisible (it's a dependency), I don't quite see
the point.

- Should 2.1.1 require python-foo to provide pythonX.Y-foo?

- Again in 2.1.1: Should any new python-foo conflict with python-base
(<= 1.5.2-18.4) so python-base has to be upgraded for python-foo to be
upgraded too?  (Could this get rid of the whole conficts problem in
python core?)

- Would it be cleaner to make all pythonX.Y-foo provide python-foo, so
any version-independent package that needs foo can depend on
python-foo?  If we did this (and got rid of the Depends funkiness) we
could throw out 2.1.1 completely, as it would be a special case of
2.1.2.

- 2.1.2.2, or some other part of the policy, should explicitly
prohibit the use of /usr/lib/site-python, as it is deprecated
upstream.

- I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good
name... maybe /usr/share/python/site-packages instead.  (After all,
the things should be arch independent.)  I'd be happy to code up the
symlink thingamajig for 2.1.2.2 if nobody's working on it.

- Perhaps instead of a dependency on python (<= X.Y+1), 2.1.2.2 should
say packages should confict with python (>> X.Y+1), unless we want to
force everyone to have the default version installed.

- Maybe the rationale should be at the beginning of section 2... it
would make the rest of the section more understandable.

- (editorial nit) There seems to be a superfluous < in the rationale.

Anyway, feel free to rip away...


Chris
-- 
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/