Re: Bug#383958: lintian: python-script-but-no-python-dep error with python-support
reassign 383958 python-support thanks Le dimanche 20 août 2006 à 17:30 -0700, Russ Allbery a écrit : > python-support is a package that, at least according to its long > description, says that it provides a script that byte-compiles Python > modules. Nothing in the description of the package says that it provides > a Python interpreter. It happens to do so *now* because of its > dependencies, but suppose there were some reason down the road why it > might depend on some specific version of Python that didn't provide the > /usr/bin/python interpreter or otherwise changes its functionality in some > way. You are 100% right. I will change the script to add the python dependency even when there is a dependency on python-support. -- .''`. 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: Future of dh_python
Le mercredi 16 août 2006 à 16:21 +0200, Raphael Hertzog a écrit : > As I can understand him, we really should respect his wish. If Matthias > agrees, > I can extract the "dependency" generation code from dh_python and create > a little perl library that would be included in the python package > (or python-dev) and that would be used by dh_pysupport and dh_pycentral. > I can also prepare patches for dh_pysupport/dh_pycentral. The changes needed in dh_pysupport are trivial. As of version 0.4, it handles dependencies in more cases than dh_python, and does it only if debian/pycompat isn't found. The only thing to do is to remove this check. I also heard that python-central has some code for dependency generation. Depending on how advanced it is, this library won't be needed at all. > dh_python would be modified to support only v1 mode (with a big > deprecation warning) and would be no-op if debian/pycompat was 2 > (including the implicit pycompat=2 set if the XS-Python-Version header is > here). Yes. > python-support/central will have to depend on the new debhelper to avoid > generating dependencies twice if dh_python is invoked (as is currently > the case for most packages). We should avoid introducing a dependency on debhelper. A mutual conflict on the older versions will do the trick. > >* -V is a redundant interface, since it does something approximating > >what debian/pyversons does. So things should be able to switch to the > >other interface, except in edge cases (although IMHO it's not an > >appropriate interface for a debhelper program), and for the edge > >cases, -V could be added to the other two programs. > > Exactly, we should get rid of the "-V" parameter completely. I strongly disagree here. The -V flag achieves something very specific (e.g. for Zope packages) and there is no way that we can get rid of it (or another interface achieving similar functionality). See #381389 for an explanation. > -X support has > been added during my NMU as it was a wishlist that I found useful (so -X > isn't widely used). Yes, we can check for the few packages using it. -- .''`. 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: Future of dh_python
On Tue, Aug 22, 2006 at 01:00:45AM +0200, Josselin Mouette wrote: > Le mercredi 16 août 2006 à 16:21 +0200, Raphael Hertzog a écrit : > > As I can understand him, we really should respect his wish. If Matthias > > agrees, > > I can extract the "dependency" generation code from dh_python and create > > a little perl library that would be included in the python package > > (or python-dev) and that would be used by dh_pysupport and dh_pycentral. > > I can also prepare patches for dh_pysupport/dh_pycentral. > > The changes needed in dh_pysupport are trivial. As of version 0.4, it > handles dependencies in more cases than dh_python, and does it only if > debian/pycompat isn't found. The only thing to do is to remove this > check. > > I also heard that python-central has some code for dependency > generation. Depending on how advanced it is, this library won't be > needed at all. Hrm, I can't help but think that one common code base for dependency generation is better (if it can be agreed upon). It means more consistency over time when things get changed and also has the obvious benefit of being tested better, not all bugs will be duplicated etc. I know these arguments could be used for pysupport/pycentral too, but at least the dependencies that need to be generated are agreed on (afaik) so why not keep it together in a little library? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Future of dh_python
Le mar 22 août 2006 01:00, Josselin Mouette a écrit : > > > * -V is a redundant interface, since it does something > > > approximating what debian/pyversons does. So things should be > > > able to switch to the other interface, except in edge cases > > > (although IMHO it's not an appropriate interface for a debhelper > > > program), and for the edge cases, -V could be added to the other > > > two programs. > > > > Exactly, we should get rid of the "-V" parameter completely. > > I strongly disagree here. The -V flag achieves something very > specific (e.g. for Zope packages) and there is no way that we can get > rid of it (or another interface achieving similar functionality). See > #381389 for an explanation. -V may also be used for packages that are not in the scope of the policy: meaning applications that do not support current python /yet/. For those, you need to build-dep upon pythonX.Y-dev (X.Y >> current) and to dh_pysupport -VX.Y. when that application will support current (e.g. because X.Y becomes current) the packaging has to be changed to use python-dev as a B-D and remove the -VX.Y call. and even with a more clever dh_pysupport (and I don't think that's doable without bloating the script) you won't spare the B-D change anyway, so it won't spare the new sourceful upload. (the same is true for applications that do not support current python *anymore*, e.g. applications that only work with python2.3 nowadays, if that exists). the policy deals with package that support current (and to some extent, for pure python modules where the python (>= X.Y) | pythonX.Y dependency kludge allow a more smooth upgrades[1]). Everything else is on its own, and there -V *is* a way to help packaging those applications. Except for the pure modules, when you package a "thing" for a specific non-current python version, you should build-depend on pythonX.Y-dev[2]. [1] I repeat this is a kludge, and only appliable to pure python modules. Given that there is quite a couple of them, it's a useful kludge though. [2] build-depending on python-all-dev is horrible as a general rule, if you build against a sole python version. Though, even for applications, there is cases where you can kludge the debian/rules to switch from a pythonX.Y only build to a /usr/bin/python one, using things like: * B-D on p-all-dev * building with a magic substitutions of $(shell pyversions -d) by "python" in the requested list of pyversions, so that when the X.Y you depend upon, you magically switch to a package built for current. Though, I really think such packaging methods are harmful, and that the python2.4-that-is-out-since-years should not happen again thanks to the new policy, so that we can assume that only *few* packages will not support the current version. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQ8e93YtZfA.pgp Description: PGP signature
Re: Future of dh_python
Hi, On Tue, 22 Aug 2006, Floris Bruynooghe wrote: > > The changes needed in dh_pysupport are trivial. As of version 0.4, it > > handles dependencies in more cases than dh_python, and does it only if > > debian/pycompat isn't found. The only thing to do is to remove this > > check. > > > > I also heard that python-central has some code for dependency > > generation. Depending on how advanced it is, this library won't be > > needed at all. Matthias, what's your opinion on this topic? > Hrm, I can't help but think that one common code base for dependency > generation is better (if it can be agreed upon). It means more > consistency over time when things get changed and also has the obvious > benefit of being tested better, not all bugs will be duplicated etc. Indeed. That's why I suggested it. And it would be sad to see all my efforts with dh_python go away as the sole purpose of the new dh_python was to assure that consistency. The code would be a little simplified as there's no need to support the "old policy" in that library. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
