Re: The Python Registrar
On Mon, Feb 25, 2002 at 09:07:53PM +0100, Bastian Kleineidam wrote:
> Hi Donovan,
>
> On Sat, Feb 23, 2002 at 10:38:17AM +1100, Donovan Baarda wrote:
> > Did you see my analysis and modified "register-python-package" script? I
> > posted it under a misleading subject by mistake (responded to another thread
> > that migrated onto it).
>
> Sorry, sometimes I have lag in responding :)
Cool... normaly I can take months, but right now I've got a bit of time :-)
> > Some things like how dependancies should work need to be resolved. The
> > sample "sperm" package has a dependancy on "python", but this doesn't really
> > express it right. This means a dependancy on any version of the "default"
> > python.
>
> Perhaps "all" is misleading, it should be "default".
Hmm, do you mean in that case it should only symlink and compile for the
current "default" python? An upgrade of the "default" python should cause
removal of the old "default" symlinks and compiles before creating the new
ones.
This effectivly breaks "legacy" support for any other versions of python.
> > This means "sperm" cannot be installed for python1.5 unless
> > "python", and hence "python2.1", is also installed. A dependancy on
> > "python1.5 | python1.6 | python2.0 | python2.1 | python2.2" would work
> > better, but then it breaks for python2.3, undermining it's claimed
> > python-central support for "all".
>
> With the current policy encouraging and centralising on a "default" Python
> version, the support for "all Python versions" is leading in the wrong
> direction.
> Remember that the other versions (the Policy calls them "legacy" versions,
> which are currently 1.5 and 2.2) are only there to provide packages
> depending on specific Python versions other than the default.
Yes, but it's nice to have support for "legacy" versions for free if we can
have it.
I think it's important to have "legacy" support without requiring package
uploads when "python" upgrades. The existing policy of pythonX.Y-foo +
python-foo as a wrapper depending on pythonX.Y-foo does just that... the old
pythonX.Y-foo becomes the "free" legacy support when python-foo upgrades.
> > This leads to some of my concerns about claiming support for "all" or
> > ">=X.Y". As one of the people who originaly provided nasty-hack code to
> > support this, I'm starting to have doubts. For starters, claming support for
> > as-yet-non-existant versions of Python is more risky than I thought. I would
> > hesitate to deny a packager the right to make such claims and deal with the
> > bug-reports when they come in, but I think it should be discoraged.
>
> Good point. Its always risky to support future versions (with "risk"
> meaning bug reports on the module).
> On the other side, thats exactly what I want with a version independent
> module: get rid of "oh, the version changed, so re-upload the thing".
Yeah... critical. Nothing I hate more than package uploads just to fix
dependancies.
> > Those who want "all" behaviour can specify "1.5 1.6 2.0 2.1 2.2 2.3". Those
> > who want ">=X.Y" behaviour can just specify "X.Y X.Y+1 ..." upto wherever
> > they feel comfortable with.
>
> I agree with you on feeling very uncomfortable to write
> "Depends: python2.3", thats not the way of a true samurai.
> But I definitely want the "Depends: python" option on a module package.
> This does not mean "version independent", but "independent of the
> default python version". In this case its up to the package maintainer
> to ensure the module works with a possible changing default python
> version.
> With your last script using the dpkg database (which is really nice),
> this should not be very difficult to achieve. I will see what code
> I can crank up for this :)
You need to be a little careful about just having "Depends: python". The
current policy uses "Depends: python (>=X.Y), python (<<X.Y+1)" to ensure
that the dependancies "break" the package when the default python upgrades
outside the supported version.
I would be inclined to encorage this in pure-python packages too. Remember
the "Depends:" must also include enough information for legacy support when
python upgrades. This means it must include information to indicate what
"pythonX.Y" versions it supports, so when they go "legacy", it still
supports them.
I can see only two ways of doing this; explicit alternative dependancies on
the pythonX.Y packages, or a pair of versioned dependancies. ie;
a) Depends: python1.5 | python1.6 | python2.0 | python2.1, python-central
- or -
b) Depends: python (>=1.5), python (<<2.2), python-central
Where they both indicate "legacy" support for python1.5 through python2.1.
Note that for the second option, a developer could optionaly omit the upper
version limit at his own risk.
The problem/benefit with a) is it does not allow an open-ended upper version
limit.
The problem with b) is it does not allow a "legacy" python-central package
to support multiple versions of python older than the current default. You
could not have python1-foo supporting python1.5 and python1.6 with "Depends:
python (>=1.5), python(<<2.0)" when "python" is at version 2.1.
The other problem with b) is it does not allow a "legacy only" installation.
It requires that "python" be installed, so you cannot just have python1.5
and python-foo installed.
If you go down the b) path, you will need to modify my dependancy parsing
stuff to pull out versions. If you go down the a) path, it's already done :-)
there are possibly some hybrids of these two that could get horrendously
complex, like;
Depends: python1.5 | python1.6 | python2.0 | python2.1 | python (>=1.5), \
python-central
These basicly require parsing both versioned depends info _and_ versioned
package info to find all the supported versions, but it would allow great
flexibility in specifying exactly what versions you support, at the cost of
confusing people. To go really over the top, you could also parse
"Conflicts:" info :-)
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: