[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python-debconf, Byte compilation and other questions



On Sat, 2003-04-19 at 15:29, Matthias Klose wrote:
> Donovan Baarda writes:
> > The things that need resolving, in no particular order;
> > 
> > 1) moving /usr/lib/python* into /usr/share/python*. I consider this low
> > priority, but something that should be done one day. There are possibly
> > some issues with separating binary extension modules from .py python
> > modules that would to be resolved.
> 
> -1
> As we change the search order, I will wait until upstream applies this
> (or at least discussed it). The right way here seems to write a PEP.

OK, mega low priority... someone on this list was crying out for it when
the policy was being developed. I didn't realise it required upstream
changes, but since it does, then we wait for upstream to change.

> > 2) python-central style support for pure-python modules that support
> > more than one version of the default python package. The current version
> > of python-central can already do this, but it is not in the standard
> > yet. I'm not sure if it should be standard untill it suppprts 3).
> 
> +1
[...]

Is this +1 for python-central style support, or waiting until it
supports 3) 

> > After having contributed to python-central, I'm still not sure it's the
> > best way to do things. It would be nice to avoid having a separate
> > package just for python installation scripts. However, it is the only
> > way I can think of to have common installation scripts available to all
> > python packages without requiring the installation of "python" (ie,
> > python1.5-foo only requires python1.5, why should it require python
> > (2.1), and hence python2.1, be installed).
> 
> what is wrong to have a default python version installed? Many
> packages already use python, so it's likely to be installed on a
> machine.
[...]

On very light systems, it is conceivable that the situation might arise
where someone only needs python1.5-foo. Having the dependencies pull in
python2.1 just to get it is something I think is worth trying to avoid.
An example of this might be an application like zope or mailman that
depends on a particular old version of Python.

> > If every python package ensured that it symlinked (if required) and
> > compiled it's .py's for every installed and supported version of python
> > in it's postinst, then doing a 'dpkg-reconfigure -p critical <package>'
> > should re-compile the package. There must be ways to use this in scripts
> > to ensure correct installation-removal of packages.
> [...]
> 
> hmm, how does this work for packages like mailman and zope, where more
> than recompilation is done in the scripts (debconf configs ...)?
> I don't want be asked these questions when I upgrade python.

The "-p critical" part of this would ensure that only critical questions
are asked, all the other questions would use the answers supplied at
install time.

In some ways this is an advantage. It is possible those "more than
recompilation" things would also need to be done when the version of
python changed. This ensures that the package is brute-force
"reconfigured" into a working state, not just the *.py's are
re-compiled". An extreme example of this might be something like a
package that includes optimisation support for different versions of
python by patching some *.py's for different versions of python. Just
recompiling the *.py's would not be enough for such a package.
 
> > The problem of dpkg-reconfigure is it brute-forces everything without
> > taking into account the specifics of what the "python status" change is.
> > Perhaps a better way to do this is to instead just call the package
> > .postinst scripts, adding a few extra "context cue" parameters to tell
> > the package what has happened. For example call
> > "/var/lib/dpkg/info/python-foo.postinst configure pythonX.Y" when
> > pythonX.Y is installed and "/var/lib/dpkg/info/python-foo.prerm
> > pythonX.Y" when pythonX.Y is removed.
> 
> Then we are at a point, where we need a <package>.python file (maybe
> in dpkg format), which contains the python specific meta information.

I'm not entirely sure what you mean by this. Is this a debhelper thing?

My personal design goals in vague order of priority are;

1) avoid additional "databases" for storing package installation
information. The existing dpkg "database" should be all that is needed.

2) avoid overkill dependencies like python1.5-foo requiring python2.1.

3) avoid excessive package updates. Updating packages just to fix
dependencies or scripts is a PITA. In particular, updating "legacy"
packages to fix conflicts with recent packages is to be avoided at all
costs. If it must be done, the best place to do it is in small sized
"wrapper" packages (you can see this design goal influence on the
current policy).

4) maximize support for multiple versions of python. This makes life for
developers much easier. It also allows packages that require old
versions of python to run on modern systems (zope etc).

5) avoid script replication, redundancy, and complexity in package
scripts.

6) avoid additional "support packages" like python-central if at all
possible.


-- 
----------------------------------------------------------------
Donovan Baarda                http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------



Reply to: