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". 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: 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). > 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. -- 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]
