On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote: > On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek <[EMAIL PROTECTED]> said:
> > On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote: > >> >> 3.1.3. Provides > >> >> Packages with public modules and extensions should be named, or > >> >> should provide, python-foo. Pure Python public modules that > >> >> support all Python versions need not have a Provides field. > >> > ... unless there is an application using a non-default python > >> > version using this module. or else you require the application > >> > depending on any indirect dependency of python-foo. > >> Hmm. Two things: if application X requires my pure python public > >> module (called, say, python-foo), and uses some specific version of > >> python, why can't it depend on just python-foo Why do I have to > >> provide pythonX.Y-foo? > > Because a dependency on "python-foo" expresses the request "give me > > the foo module for the current version of python". > No, it does not. When a package bar depend on package baz, it > means just that-- that it requires the package baz to work. With the > policy draft that I have proposed, if it is a pure python module, > with no intrinsic restrictions on the versions of python supported, > other packages can just depend on the package, knowing that a policy > compliant package would support all available versions. Then what do you name a package that is a pure python module that *DOES* have intrinsic restrictions on the version of python supported? You are wrong to assume that a pure python module will automatically support all available versions of python -- if all python versions were completely backwards- and forwards-compatible with one another, there would be no reason in the first place to *have* multiple versions of them in the archive. The reality is that there *are* language differences with each implementation of python, and a pure python module may *not* work with any given implementation of python available in the archive, and we need a way to express such dependencies that guards users against package relationships being satisfied by broken combinations. > > There is no guarantee that the python-foo package installed is > > compatible with, or provides support for, the pythonX.Y you're > > using, except if this package declares a Provides: pythonX.Y-foo; so > > the depends/provides: > Rubissh. You are just making up these rules, and since it > hurts, just don't make them up. What hurts is your ignorance of design requirements that were discussed at length at the DebConf python BoF. > If you want a pure python module that complies with the new policy, and > does not provide pythonX.Y-foo; you know trhat you can just depend on > python-foo, and things shall work. No, only packages that invoke /usr/bin/python as interpreter can do this. Packages that invoke /usr/bin/pythonX.Y can't possibly have any forward guarantee that python-foo will provide a working interface for the version of pythonX.Y they have installed. > > pythonX.Y-foo needs to be there to ensure that the app and the > > modules it needs aren't allowed to get out of sync on a user's > > system (or in testing). > And why would they get out of sync. If they are compliant, then > when a new python version is installed the module is compiled for it -- so > no matter what version of python you use, there is a compiled .pyc file > there. Python decorators are a language feature available only in python 2.4 and above. Given a module foo version 1.0 which does not use decorators, a module foo version 2.0 which does, and a package bar which invokes /usr/bin/python2.3 and depends on "python2.3, python-foo", how do you protect against installing python-foo 2.0 and breaking bar? It doesn't matter a bit whether the .pyc is in the python2.3 search path when the module in question isn't compatible with that version of the language. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]