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. > 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. 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. > 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. >> Also, as a maintainer of python-foo, I can't know when such an >> application would be created, and we are trying to minimize >> reuploads of packages -- so either one provides all such >> pythonX.Y-foo at the get go, and reupload at every new python >> version or dropping of the old version -- or we upload every time >> some app is uploaded that may require yet abother X.y, and when we >> drop a version of Python. > Such apps would ideally be few and far between, but after thinking > about it for a while, I wasn't actually able to come up with a > concrete case where having the Provides: declared ahead of time > complicates transitions more than not having them would. For pure > python modules, this still means inconvenient sourceful reuploads > when new python implementations become available, since the > Provides: can't be declared for pythonX.Y that we don't yet know > about, but fortunately those reuploads would only need to be done on > demand for modules that are actually used from scripts invoking a > non-default python interpreter. And if you just follow the new policy, no uploads are needed at all. The new policy wins. manoj -- America: born free and taxed to death. Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]