Bastian Kleineidam writes: > On Sat, Aug 24, 2002 at 07:48:31PM +0200, Matthias Klose wrote: > > Some comments: > > > > - python-central should have a configuration option, how files are > > compiled. Most users don't need compilation with -O. > I will have commandline options for this, so the module packager can > decide what to compile or not. > > > Maybe a debconf option? > This would enable the user, not the packager, to decide compilation.
yes, exactly this. The user should be enabled, not the packager. > After a dpkg-reconfigure, there would have to be either a recompile > or a .py[co] file cleaning. I will make this later, not in the 0.x > versions. Fine. > > - A package should have the possibility that it's incompatibe with > > a specific python version or that it only works with specific > > versions. > This is done by only depending on the supported Python versions, eg > Depends: python1.5 | python2.2 saw Donovans comments. Maybe this is the safer option. > > - A command is missing to recompile all registered packages when > > the default python version changes. > There is nothing in python-central about the default "python" > packages, only versioned "pythonX.Y" packages are considered. > So it is safe to change the default Python version without > touching python-central. > > > - How do packages like mailman make profit from python-central? > > They don't install into /usr/lib/python/site-packages, but > > their python files need to be recompiled on a python version > > change. > Mailman should put his modules in /usr/lib/python/site-packages. > Of course packagers can put their stuff in /usr/share/<package>/ > or /usr/lib/<package> and use their own Python-version-compile > script, but then they are on their own. ok, if you call the package python-library-central and the command register-python-library(1), I'll agree. But as I pointed out to Donovan, there are applications, which use more than one .py to modularize the application, but don't provide a library. These packages *should* put their in /usr/lib/<foo> or /usr/share/<foo>. Please do support packaging these pure python application packages! maybe mailman here is a bad example, because it has some libraries which could be reused in another application. Matthias