[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python-central vs python-support



Coin,

Matthias Klose <doko@cs.tu-berlin.de> writes:

> s/available/supported/. we will try to keep the number of supported
> python versions/implementations minimal.

Is there difference between available and supported versions ? What use
for an official python package if it is not supported ?

> Plus XS-Python-Version, from which XC-Python-Version is generated from.

Why is this necessary ? You said you plan on having a dh_pycentral
script, why can't this one do the job automagically ? Why having the XC-
remain in package information then ?

>> 3) The tight upper bound on module dependencies will be removed,
>> provided the module actually works on future versions of Python. The
>> upper bound on extension dependencies will not, because then they
>> wouldn't work.

I don't see any reason to keep this boundary, really, as you plan to use
binNMUs on transitions. Either the extension does not work on a newly
uploaded python version after being binNMU-ed, then this is a bug (not
grave), or you use a boundary for an extension which would have worked
perfectly and this is a bug too. As this is of the same severity, i
would rather have to consider a bug for an upstream lack of support for
a new version rather than for my extensions because of fear.

>> 4) python2.x-* virtual packages are to be used only when necessary, but
>> packages can provide them regardless.
>
> you don't know in advance, if they are necessary. Not a problem, if
> they are generated.

Yes i agree. But what a pollution. Now when Ruby and other langages would
do the same, i'd like to know how long apt would be...

>> 2) is suspect. It's not required for multiversion support *in policy*.
>> The working python-support implementation in unstable, while still
>> lacking such fields, proves that. I feel it's much more of an
>> implementation issue than a policy one, and so if we don't use
>> python-central (which I gather is the impetus for it), we shouldn't
>> bother with the control field either.
>
> we agreed to use this information so that you can decide on package
> rebuilds based on the Sources and Packages files. See my slides from
> Debconf.

Where are those slides ? Should we be aware where your things are
stored ?

Don't you think this new field and Provides are redondant, and that you
could decide which rebuilds are necessary from it ?

-- 
Marc Dequènes (Duck)

Attachment: pgpIKyrCa86Lu.pgp
Description: PGP signature


Reply to: