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

Re: dpkg-repack warnings: what effect?



On Tue, 2006-07-25 at 02:07 +0200, Adeodato Simó wrote:
> * Matthias Klose [Tue, 25 Jul 2006 00:56:29 +0200]:
> 
> > > > I agree that having Python-Version in binary packages is dislikeable.
> > > > Out of curiosity, Matthias, would be a DEBIAN/pyversions file able to
> > > > provide the same information to pycentral?
>                        ^^^^^^^^^^^
> 
> > just looking at the Packages (and the Sources) files.
> 
> Yeah, I knew this was the reason for putting the info in the headers, I
> understand that. But I was only asking if pycentral itself would have
> enough with DEBIAN/pyversions, which is different from implying that I'd
> rather have pycentral use D/pv at the cost of losing the benefits of
> having that info in the Packages file. ;-)
> 
> I assume the answer to this question is yes, yes?
> 
> Now, I have a sequence of events that have left me puzzled:
> 
>   - After writing the above, I intended to ask why XB-Python-Version was
>     necessary in the Packages file, if that information was already in
>     Sources via XS-Python-Version.
> 
>   - But then I thought: "d'oh, obvious: XB-P-V must be an _expanded_
>     version of XS-P-V, with a plain list of python version the package
>     was built for, and this is much easier to parse than an expresion
>     with >= and <<, plus only with XS-P-V you can't know e.g. if a
>     binNMU after dropping 2.3 was successful or not".
> 
>   - But after that, I quickly discover that my assumption is wrong, and
>     the archive contains a number of binary packages whose Python-Version
>     header contains [<=>], and it's in fact the same as P-V in the
>     source package.

If the package contains binary modules, it should only contain the
explicit list of versions it was compiled for. But if the package does
not contain any binary modules, XS-P-V and XB-P-V will be identical,
since nothing gets "built" and new versions can be supported without a
binNMU.

There is no reason this information can't, in theory, be contained in an
installed file like DEBIAN/pyversions. You'd need to use the lintian lab
or something similar to track rebuilds, but you'd not seriously lose any
features. But please, don't make any more "cosmetic" feature/change
requests until after the transition actually happens.

(Or, finally announce that Python 2.4 is plain too late for etch. Then
people can have as long as they want to debate over this crap, and
Python developers can just give up hope.)
-- 
Joe Wreschnig <piman@sacredchao.net>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: