Re: Python upgrade: dependency question
> An added complication is that I'd like to merge the mpz, gdbm, curses,
> bsddb, net and stdwin packages back into python-misc.
You may want to keep python-mpz, python-curses, and python-gdbm as
separate packages, because they depend on gmp2, ncurses3.4, and
libgdbmg1 (respectively). If they are merged into python-misc, then
those libraries have to be installed even if the python modules that
need them are never used.
> One problem is that python-base-1.4 is needed in the postrm's of all the
> other 1.4 packages, therefore -base has to be the last to be replaced.
> OTOH, base-1.5 should conflict with base (<< 1.5), while misc-1.5 will
> depend on base (= 1.5), so I can't simple replace misc-1.4 and friends
> with misc-1.5.
Let's see... I have stared at the packaging manual, section 6.3
("Details of unpack phase of installation or upgrade"), and I think
this can be made to work correctly.
You see, step 5 says:
1. If the package is being upgraded, call
old-postrm upgrade new-version
2. If this fails, dpkg will attempt:
new-postrm failed-upgrade old-version
If python-base is upgraded before (say) python-misc, then the postrm
from python-misc 1.4 will fail because
/usr/lib/python1.4/compileall.py is no longer there. Then dpkg will
call the new postrm, which can check for the argument "failed-upgrade"
and a version number that starts with 1.4. There you can add code
to handle the problem.
The main task of the compileall call in the postrm of these packages
is to remove the .pyc files of the python modules that have been
removed. One way to do this is to explicitly list the .pyc files to
remove. Another would be with a new option to compileall.py (only
delete, don't recompile), or with a bit of shell programming.
Richard Braakman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: