> 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 [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .