Moinmoin does not work after upgrading python from 2.2 to 2.3. Checking out the collection of python related directories in /usr/lib (python2.1, python2.2, and python2.3), it looks like various apps that installed files in the site-packages directory have migrated to the most recent version of python with the exception of MoinMoin which only exists in the python2.2. The obvious work around for this problem is to manually emerge moinmoin after the python upgrade. This works, unfortunately the moinmoin ebuild over writes the htdocs/moinmoin/moin_config.py file, deleting the basic site custom configuration. Reproducible: Didn't try Steps to Reproduce: 1. emerge python 2.2 2. emerge moinmoin 3. emerge python 2.3 Actual Results: The moinmoin installation stopped working. Expected Results: Moinmoin should have been re-emerged after the python emerge. This should have removed the python2.2/site-packages/MoinMoin directory and installed python2.3/site-packages/MoinMoin. piste lib # emerge info Portage 2.0.51-r2 (default-x86-1.4, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.4.26-gentoo-r9 i686) ================================================================= System uname: 2.4.26-gentoo-r9 i686 AMD Duron(tm) Processor Gentoo Base System version 1.4.16 distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 Headers: sys-kernel/linux-headers-2.4.19-r1,sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -funroll-loops -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -funroll-loops -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc distlocks sandbox" GENTOO_MIRRORS="http://128.213.5.34/gentoo/ http://cudlug.cudenver.edu/gentoo/ http://gentoo.noved.org/ http://mirror.tucdemonic.org/gentoo/ http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X alsa apache2 apm arts avi berkdb bitmap-fonts bonobo cdr cjk crypt cups curl dga directfb doc dvd emacs encode esd ethereal f77 fastcgi fbcon foomaticdb gb gd gdbm gif gnome gpm gtk gtk2 gtkhtml guile imap imlib innodb java jpeg kde libg++ libwww mad maildir mikmod mmx motif mozilla mpeg mysql ncurses nls odbc ofx oggvorbis opengl oss pam pda pdflib perl png python qt quicktime quotes readline ruby samba sasl sdl slang slp spell sse ssl svga tcltk tcpd tiff truetype unicode usb wmf x86 xml xml2 xmms xprint xv zeo zlib" piste lib #
See also bug #68859 which showed up at the same time. These two bugs may really be a python ebuild problem.
Did you run /usr/sbin/python-updater after upgrading to python 2.3?
No I didn't. This upgrade was part of an emerge -uD world, so any einfo or ewarn messages were lost in the mists of time as per bug #11359. I will update bug #68859 with this info. Is it safe for python-updater to always be run as part of the post install? If not, can it be made safe?
Yes, it can be run as many times as you want, in case a package in the list fails to emerge. You can also do a 'python-updated -p' to just see a list of what will be upgraded. I'll leave this bug open since there is still a problem with that config file being overwritten.
Sorry, I should have been a little more explicit. Can python-updater be run automatically as part of emerge python? Or could it be called in revdep-rebuild? That way people only have to know about one command to run after an emerge system/world.
unfortunately, i'm not confident that we should be running emerge inside emerge, which is what that script does. maybe wei'll figure something out for python-2.4
It sounds like this is actually a limitation of portage. It might be best if portage supported the concept of a reverse dependency, so that add-ons like revdep-rebuild and python-updater were no longer needed. In that absence, I think the pragmatic hack would be to modify revdep-rebuild to check for an installed python-updater and then call it with the same command line arguments (as revdep-rebuild) if it exists. Of course revdep-rebuild could be extended to any other ebuilds that have the same sort of reverse dependencies. That way people would only have to run one catch-all command to ensure that all of the reverse dependencies were in sync.
Changed the summary to reflect the problems left, now that bug #73978 has been opened to deal with the python-updater issue.
In bug #67311 I mentioned that the ebuild also overwrote FrontPage. I have closed dup that bug against this one to reduce the excess verbiage.
*** Bug 67311 has been marked as a duplicate of this bug. ***
1.3.5 is in the tree, should not overwrite the config files anymore. Please test and reopen if necessary.
Closing
