Re: python-central comments

[Matthias Klose <doko@cs.tu-berlin.de>]

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