Re: coming back to packaging multiple versions of libraries
[Robert Collins, 2011-01-03] > whats the simplest way to install this somewhere else - e.g. > /usr/share/pyshared/wadllib-1.1.4 > and have > import wadllib > still work without user intervention. > > Two options seem to present themselves to me at the moment: > - the pyshared symlink logic could select the highest version and > link that into /usr/lib/.../wadllib as well as into > /usr/lib/.../wadllib-1.1.4 >- possibly using a single wadllib->wadllib-1.1.4 symlink, or > possibly using the 'normal' structure of directories + per-file links. > - we could drop the versioned path into site.py in the same way > python-numeric etc do what's the point of installing two different versions of the same module if only one will be used anyway? If the answer to that question is: "in the application where I need different version, I will adjust sys.path" - why not simply provide different version of the library as private module? Security team will hate you anyway. > I'm very interested in other approaches to make this work; teach upstream about the importance of stable API (yeah, I know Python programmers do not care about it much, it could be worse¹, though) You could also provide wadllib/__init__.py file which will modify __path__ to point to the newest installed versions (and f.e. check for WADLIBVERSION env. variable if someone doesn't want the newest version) but it's an ugly hack and could cause more harm than good, IMHO. [¹] imagine packaging something written in Ruby -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110103081200.gj18...@piotro.eu
Re: Compressing objects.inv?
Le lundi 03 janvier 2011 à 00:17 +0100, Michael Fladischer a écrit : > Some packages (e.g. python-sphinx itself) ship a gzip compressed > objects.inv.gz (it seems to me that dh_compress triggers this during > build) but sphinx.ext.intersphinx is not able to read compressed files. If it’s done by dh_compress, this can be trivially fixed in debhelper itself. I remember having to do this for similar reasons for debhelp. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1294052024.4333.8.ca...@meh
Re: Compressing objects.inv?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Dne Mon, 03 Jan 2011 12:31:29 +0100 Michael Fladischer napsal(a): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Josselin Mouette, 2011-01-03 11:53: > > If it’s done by dh_compress, this can be trivially fixed in debhelper > > itself. I remember having to do this for similar reasons for debhelp. > > You mean by adding it to the hardcoded list of exceptions in > dh_compress? I could send a patch to the debhelper maintainers if this > would be the preferred path (although I already did a mass-bug-filing). > > I was thinking about a lintian check but I lack lintian/perl foo to do > this in a timely manner. Filing wishlist bug agains lintian would help as well so that it is not forgotten. - -- Michal Čihař | http://cihar.com | http://blog.cihar.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAEBCAAGBQJNIcjcAAoJEGo39bHX+xdN3rUP/AsA5pY9rMk1Pf5wTf3LadQf bSiX6MIFiyToQanfoRpXUqrjUJ35QRgPdSL8GD7NVuy48yTIfe9DWDA34ixMg2HT ngXhpo2B0nwI++qZGWOqkCrsIRH2vvNHeIWqI3c8JRTuXoIAu5st4x6V4CSDxoVr bZsEUm39BijM/DuBy5KNaoxQdNPocIid+awqUXHN7tclkTw807G8Y+AS5diF+q2q xlzcEjDBNYvqqCXZLH9toHQdMFeO6U8YRCduW5xXv1MJpNQvpLMhbJA/LIDAVzMD 4L9fzIOCKERw3EHkb8OLJdDhmAFZUjImiAIcgxDcqlPHaG9zt0lutr9cezqLTfEo 9gpnCYzJKGy4nYIcrL0BYpp4dt0aDBg5lOIZm44P8dUn3z/PsTp4G0mivUj9G955 deUMZO8ZXn4mNIXszp0bgrR5i/mnD30auoLYoCVvC8c+Vur1pmgsjUSp4HqjypY1 EBxMjF605TxAxm8gYYaN9dn+xesaXfPcwgTCVWylb4x0mFe0cLAe+glYpwctYxZU AA+vtkHGeydTU3vYkCwQl12mfqb0EwXQNRDQLBeGny1e9a6kmsV8A21K+1xTCqFt 0T6hHeQEYP9bSVeHq+Vj9lCYzcKqrDix8B2K05qVuH6+Qbm0f3s71bmgzmILnPOR D3M1Lw90bEnYMCxWD/ob =HUiC -END PGP SIGNATURE-
Re: Compressing objects.inv?
Hi Michael (2011.01.03_13:31:29_+0200) > You mean by adding it to the hardcoded list of exceptions in > dh_compress? I could send a patch to the debhelper maintainers if this > would be the preferred path (although I already did a mass-bug-filing). Also worth noting is .js, which sphinx docs include, and get compressed by default. > I was thinking about a lintian check but I lack lintian/perl foo to do > this in a timely manner. If someone is doing that, there's also the missing _sources issue [0], although that's a lot harder to detect (you need to identify a sphinx docs subtree...) [0]: http://lists.debian.org/20101108231614.gu12...@onerussian.com SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110103141828.gy11...@bach.rivera.co.za
Re: Compressing objects.inv?
Hi Dne Mon, 3 Jan 2011 16:18:28 +0200 Stefano Rivera napsal(a): > Hi Michael (2011.01.03_13:31:29_+0200) > > You mean by adding it to the hardcoded list of exceptions in > > dh_compress? I could send a patch to the debhelper maintainers if this > > would be the preferred path (although I already did a mass-bug-filing). > > Also worth noting is .js, which sphinx docs include, and get compressed > by default. > > > I was thinking about a lintian check but I lack lintian/perl foo to do > > this in a timely manner. > > If someone is doing that, there's also the missing _sources issue [0], > although that's a lot harder to detect (you need to identify a sphinx > docs subtree...) I guess broken search is rather caused by compressed .doctree files, but I might be wrong. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Compressing objects.inv?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yaroslav Halchenko, 2011-01-03 02:57: > cool extension -- any plans to develop/contribute a handler for > DBTS? Yes, I hope to be able to integrate python-debianbts as a handler later on. - -- Michael Fladischer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0hsaEACgkQeJ3z1zFMUGZ4twCeJpsPh+8f/C5++HSe87tW+fLZ Ik4An0EyKjoihwrpN58g03bkZy71VSIe =iuZD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d21b1a1.90...@fladi.at
Re: Compressing objects.inv?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Wilk, 2011-01-03 01:27: > For python-sphinx, I've just committed a fix, thanks. > List of affected packages: I've filed bugs with severity minor to all (30) affected packages (except python-sphinx, thanks for the quick fix :-) ). - -- Michael Fladischer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0hslQACgkQeJ3z1zFMUGZN/gCgk4mGPuLfTcyYKH4R+CdnmzQz VNQAoIi+Ghdzwk8EG6tAfwa50iYD6952 =mAeW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d21b255.2090...@fladi.at
Re: Compressing objects.inv?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josselin Mouette, 2011-01-03 11:53: > If it’s done by dh_compress, this can be trivially fixed in debhelper > itself. I remember having to do this for similar reasons for debhelp. You mean by adding it to the hardcoded list of exceptions in dh_compress? I could send a patch to the debhelper maintainers if this would be the preferred path (although I already did a mass-bug-filing). I was thinking about a lintian check but I lack lintian/perl foo to do this in a timely manner. Regards, - -- Michael Fladischer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0hs5EACgkQeJ3z1zFMUGZWpQCfYiuOqkKd+Rt5pbQSr2yPz5g6 h44AoIb/ohhCXtjyFSAwRBwbI9nvFRmv =JJQl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d21b391.6070...@fladi.at
Re: Compressing objects.inv?
Le Mon, 3 Jan 2011 14:02:20 +0100, Michal Čihař a écrit : > > I was thinking about a lintian check but I lack lintian/perl foo to do > > this in a timely manner. > > Filing wishlist bug agains lintian would help as well so that it is not > forgotten. +1, I already sent a patch to avoid javascript (.js) compression. Thoses javascript are also used by sphinx for the search engine. It seems that a patch was already applyed to debhelper [1] It would be nice to have a lintian check to fix the sphinx search engine also [2]. It seems that all sphinx generated documentation is affected by this compression unless overriding the dh_compress with something like 12 # do not compress the javascript files generated by sphinx 13 # if compressed the documentation search engine is broken. 14 override_dh_compress: 15 dh_compress -X.js So it seems thaht we need no compression of the .js files under /usr/share/doc//html and presence of HAS_SOURCE: false in search.html or build without '_sources': html_copy_source = False [1] http://git.debian.org/?p=debhelper/debhelper.git;a=commitdiff;h=030b3d807fb91a5bb7e61b3b47c8ca971de880ef [2] http://lists.debian.org/20101108231614.gu12...@onerussian.com See you Frederic -- GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel signature.asc Description: PGP signature
Re: Compressing objects.inv?
* Michal Čihař , 2011-01-03, 15:30: If someone is doing that, there's also the missing _sources issue [0], although that's a lot harder to detect (you need to identify a sphinx docs subtree...) I guess broken search is rather caused by compressed .doctree files, but I might be wrong. You mean files in .doctrees/ subdirectory? They are cache files and shouldn't be shipped binary packages at all. -- Jakub Wilk signature.asc Description: Digital signature
Re: Compressing objects.inv?
Hi Dne Mon, 3 Jan 2011 15:45:04 +0100 Jakub Wilk napsal(a): > * Michal Čihař , 2011-01-03, 15:30: > >>If someone is doing that, there's also the missing _sources issue [0], > >>although that's a lot harder to detect (you need to identify a sphinx > >>docs subtree...) > >I guess broken search is rather caused by compressed .doctree files, > >but I might be wrong. > > You mean files in .doctrees/ subdirectory? They are cache files and > shouldn't be shipped binary packages at all. What sounds like another good check for lintian. Didn't know that. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: coming back to packaging multiple versions of libraries
Robert brings this up every time I see him. :) I'm glad we're still talking about it; while I'm sympathetic to the use case, it just seems like a problem fraught with difficulties. One question is whether the entire Debian packaging system knows that there are multiple versions of a package available, and how it handles that. Note that this happens in other cases and AFAIK it's always resolved by including the version number in the package name (gir1.0/gir1.2 comes to mind). So, would you have packages python-wadllib1.1.4 and python-wadllib1.2 in the archive? That's going to get pretty unwieldy as a general policy. Or maybe all supported versions of wadllib get installed when you install python-wadllib, but then packages get bigger and the Debian maintainer still has to manage the complexity of multiple versions (e.g. when can you drop wadllib 1.1.4?). We see similar solutions in the Python world, what with unittest2, httplib2, and so on (heck, even Python3 ;). These are usually reserved for more severe and deliberate API breaks, such as rewrites. Unfortunately, we usually have to live with the ugly module names forever. Piotr makes other good points, so just a few additional comments. On Jan 03, 2011, at 09:12 AM, Piotr Ożarowski wrote: >teach upstream about the importance of stable API (yeah, I know Python >programmers do not care about it much, it could be worse¹, though) Not all upstreams are bad at this, or perhaps a better way of saying this is that many are good at maintaining stable APIs. It's not really a Python thing, since the quality, stability, and guarantees of Python libraries probably run the gamut as much as libraries in any other language ( BerkeleyDB ). The standard library strives for this with stated policy (PEP 387) but it's tricky. For example, sometimes you have to forego a bug fix because the only way to fix it properly is to break the API. You can sometimes play tricks (e.g. add optional args to the end of the parameters, or a parallel function) but you have to have backward compatibility as a firm principle of your software development. I do think that if a library you care about breaks compatibility, you should file bugs and be tenacious about them. In wadllib's case, you know the developers and might even have write permissions to the tree. :) The stdlib is made more difficult IMO by the batteries-included philosophy. Meaning, individual modules generally lose their own identifiable versioning when pulled into the stdlib, and only get multiple versions for deliberate major breaks described above, e.g. we ship both urllib and urllib2. >You could also provide wadllib/__init__.py file which will modify >__path__ to point to the newest installed versions (and f.e. check for >WADLIBVERSION env. variable if someone doesn't want the newest version) >but it's an ugly hack and could cause more harm than good, IMHO. Agreed. It would be more useful for the wadllib developers to work harder at keeping a stable API between minor versions. If the API breaks, bump the major version number. Then the distros can do all the difficult work of analyzing dependencies, and deciding when and how to transition to the new version. This happens all the time. Don't give up though Robert! I think the problem is bigger than just Python, but if anyone can come up with some innovative ideas that could work, you can! -Barry signature.asc Description: PGP signature
Re: Compressing objects.inv?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Čihař, 2011-01-03 14:02: > Filing wishlist bug agains lintian would help as well so that it is not > forgotten. I've filed a bug with a patch attached: #608810 - -- Michael Fladischer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0iBZ4ACgkQeJ3z1zFMUGa/iACfWESSM/upFcvmAQUtoFP9MQc5 6roAnjG4erRR/zMQC7Sj4HpAtEODIP60 =YMwS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d22059e.9090...@fladi.at
Re: coming back to packaging multiple versions of libraries
On Mon, Jan 3, 2011 at 9:12 PM, Piotr Ożarowski wrote: > what's the point of installing two different versions of the same module > if only one will be used anyway? If the answer to that question is: > "in the application where I need different version, I will adjust > sys.path" - why not simply provide different version of the library as > private module? Security team will hate you anyway. For the same reason we support libreadline5 and 6 : to transition higher level code without a flag day across the entire machine. Security team should not hate this any more or less than they do for C libraries, its for precisely the same reasons. >> I'm very interested in other approaches to make this work; > > teach upstream about the importance of stable API (yeah, I know Python > programmers do not care about it much, it could be worse¹, though) The best of intentions still sometimes leads to incompatible changes, but yeah, preach it :). > You could also provide wadllib/__init__.py file which will modify > __path__ to point to the newest installed versions (and f.e. check for > WADLIBVERSION env. variable if someone doesn't want the newest version) > but it's an ugly hack and could cause more harm than good, IMHO. I can see that breaking overly-clever packages, or things like the twisted splitup, bzrlib.plugins etc. I'd like to be minimally invasive. @Barry: yes, the C/C++/CLR/ library handling is precisely equivalent. I would expect only as many concurrent versions in the archive as we need to support. There are two use cases: - in sid, while transitioning an incompatible change - users using private packages with their own archive In the former case, we'd generally(1) drop an old version as soon as its rdepends(2) is empty. In the latter case, its up to the user to decide when they don't need a particular version. (1) Exceptions might occur if a maintainer feels that the package is extremely widely used outside of the packaging universe and wants to keep it available. (2) Figuring out rdepends sanely is another step to be taken, but I'm hoping to break this down far enough to get consensus on individual bits. It really does look like having better upstream facilities would make this a no-brainer for us; what I'd like to achieve though is something that /works/ for the existing python platform - for 2.7 which will be around a good long time, and then we'll have plenty of data to discuss with upstream. -Rob -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim7joembx_7nhtpb2mpkaq-9iiet7txbp8cp...@mail.gmail.com
Re: Bug#524176: AM_PATH_PYTHON should honor python's idea about the site directory
reassign 524176 automake fixed 524176 1.11 thanks * Matthias Klose (d...@debian.org) wrote: > On 23.03.2010 21:21, Jonathan Wiltshire wrote: > >Hi, > > > >Do you have any indication of when this bug will be closed? It's currently > >holding up the (proper) fixes for several bugs key to the Python 2.6 > >transition, that we want to get over and done as soon as possible. > > > >We can make ugly patches, but fixing this bug would reduce the work needed > >to merely binNMUing the affected packages, if I have understood it > >correctly. > > it is fixed upstream in automake 1.11 (and in Debian), so you could > use this version; I doubt that it will allow more binNMUs, as > autoconf isn't called during the build for many packages. Reassigning to the current version of automake and closing. -- Eric Dorland ICQ: #61138586, Jabber: ho...@jabber.com signature.asc Description: Digital signature
