Re: dpkg-repack warnings: what effect?
(Matthias drew my attention to this thread. Sorry I'm a bit late ...) Joey Hess [EMAIL PROTECTED] wrote: Matthias Klose wrote: I haven't yet seen any reasoning why people are seeing that information as cluttering the database or just as ugly. Causing unrelated programs like dpkg-repack to spew warning messages is, by definition, ugly. Using X- fields, which are intended for nonstandard extensions, in the core of Debian is also ugly. The reason the X*- fields have to be named like that in the package control file is that dpkg-source et al don't know which output control files to copy them into. I don't think there's anything inherently wrong with using X*- fields in a Debian-mandated way. The alternative would be to make the whole new mechanism depend on updated dpkg-source which seems pointless given that dpkg-source has an extension mechanism here for precisely this purpose. It would be nice if dpkg-source (and dpkg-deb) could be taught not to warn about this field. But the warning is harmless too: it's there to point out if you accidentally misspelling a field name. So ignoring the warning is fine. Modify dpkg to properly add new fields if they're going to have common usage in Debian. Using X- fields is fine for prototyping but not for final implementations. I disagree. One of the things the IETF discovered was that renaming fields (or things in other namespaces) causes a lot of trouble and is to be avoided. So in general new IETF standards don't expect you to use x-* for new standards-track activities. Existing X-* fields have in some cases been grandfathered. We have to use X- for these fields for the reasons I've explained above. So I think we should be prepared to officially bless these particular names. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-repack warnings: what effect?
Le lundi 24 juillet 2006 à 23:18 -0500, Joe Wreschnig a écrit : (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.) Well, isn't the whole purpose of that new policy stuff to delay python 2.4? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: dpkg-repack warnings: what effect?
On Tue, 2006-07-25 at 14:27 +0200, Josselin Mouette wrote: Le lundi 24 juillet 2006 à 23:18 -0500, Joe Wreschnig a écrit : (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.) Well, isn't the whole purpose of that new policy stuff to delay python 2.4? Oh, so it's not possible for someone to be an irresponsible maintainer without being an Ubuntu shill as well? When did they hire you, then? (Yes, this message isn't constructive, but I'm beyond caring.) -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: dpkg-repack warnings: what effect?
Le lun 24 juillet 2006 16:26, Joey Hess a écrit : Hugo Vanwoerkom wrote: dpkg-repack (from sid dpkg 1.13.22) gives warnings when repacking python packages: ... warning, `./dpkg-repack-5343/DEBIAN/control' contains user-defined field `Python-Version' ... What effect does this have? Can the .deb be used or not? It's harmless, though perhaps a pity that the python maintainers decided on this ugly solution. just FYI, it's not mandatory, one can use debian/pyversions instead (with python-support). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTiadqojggg.pgp Description: PGP signature
Re: dpkg-repack warnings: what effect?
* Pierre Habouzit [Mon, 24 Jul 2006 17:11:14 +0200]: just FYI, it's not mandatory [XB-Python-Version], one can use debian/pyversions instead (with python-support). Hm. I can see how debian/pyversions can substitute XS-Python-Version (both are available only at build time), but I fail to see how it can substitute XB-Python-Version which is presumably needed at install time. (I'm not very familiar with how pycentral works, though.) 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? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Hooverphonic - Human Interest -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-repack warnings: what effect?
Le lun 24 juillet 2006 19:52, Adeodato Simó a écrit : * Pierre Habouzit [Mon, 24 Jul 2006 17:11:14 +0200]: just FYI, it's not mandatory [XB-Python-Version], one can use debian/pyversions instead (with python-support). Hm. I can see how debian/pyversions can substitute XS-Python-Version (both are available only at build time), but I fail to see how it can substitute XB-Python-Version which is presumably needed at install time. (I'm not very familiar with how pycentral works, though.) 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? I don't know pycentral at all, and not pysupport enough to know *why*, but I know for sure pysupport do not need the XB-Python-Version at all. afaict, it seems reading the code that it uses a special custom registry in /usr/share/python-version/.version or sth like that. if you need more insight on this, ask Josselin, I suppose he can tell you how that works deep inside. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRRaazQmsJX.pgp Description: PGP signature
Re: dpkg-repack warnings: what effect?
(Thanks for the CC.) Matthias Klose wrote: I haven't yet seen any reasoning why people are seeing that information as cluttering the database or just as ugly. Causing unrelated programs like dpkg-repack to spew warning messages is, by definition, ugly. Using X- fields, which are intended for nonstandard extensions, in the core of Debian is also ugly. Same thing with a missing attribute Homepage, which often is hidden in the description anyway. Modify dpkg to properly add new fields if they're going to have common usage in Debian. Using X- fields is fine for prototyping but not for final implementations. -- see shy jo, hyprocritically signature.asc Description: Digital signature
Re: dpkg-repack warnings: what effect?
* 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. With this, I'm puzzled, since I fail to understand what information you can obtain from Packages.gz that you can't from Sources.gz? (The point of this exercise being that it'd be incredibly great if Python-Version would be only present in source packages, and not in binaries, which contain DEBIAN/pyversions instead.) Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Massive Attack - Group Four -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
