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: (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: (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: (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!"

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

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

[Gregor Hoffleit]

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.

Gregor