I ran python-updater -i -p after upgrading python, but since 16 of the packages were going to be downgraded (Because I had emerged them using ACCEPT_KEYWORDS="~x86") I had to emerge those by hand. After successfully doing so, I ran python-updater again and it appears to be listing the same packages, with the same 16 downgrades. The -dmanual option had the same result (in terms of downgrades anyway). -dmanual -dpylibdir still shows 12 downgrades. Is this the usual behavior?
Which version of python-updater? Looks like bug #232467 to me. IOW, version 0.6 should be good.
With -dmanual -dpylibdir, it's only checking dynamic links to python libraries, so I don't have the same problem they do. I think my packages are still being built against python-2.4. I have no idea how to fix this. Can anyone help please?
Here's my emerge info: emerge --info Portage 2.1.4.4 (default-linux/x86/2007.0/desktop, gcc-3.4.6, glibc-2.6.1-r0, 2.6.22-gentoo-r5 i686) ================================================================= System uname: 2.6.22-gentoo-r5 i686 Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz Timestamp of tree: Sat, 23 Aug 2008 21:00:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.6 dev-lang/python: 2.4.4-r13, 2.5.2-r6 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -Os -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium4 -Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LC_ALL="en_GB.UTF-8" LINGUAS="en_GB" MAKEOPTS="" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/pro-audio /usr/portage/local/layman/sunrise /usr/portage/local/layman/zugaina /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="16bit X Xaw3d a52 aac aalib acl acpi aim alsa amr amrnb amrwb amuled ao asf audacious audiofile background bash-completion bdf berkdb bidi bittorrent blender-game browserplugin bzip2 cairo caps cddb cdio cdr chardet cjk cli context cracklib crypt cscope css ctype cups curl curlwrappers cyrillic dba dbus dga directfb djvu doc dri dts dvd dvdr dvdread ecc eds emboss encode epydoc ethereal evo examples exif expat extra fam fastbuild fbcon ffmpeg finger firebird firefox flac fluidsynth font-server force-cgi-redirect fortran fpx ftp games gcrypt gd gdbm ggi gif glut glx gnutls gopher gpm grammar graphics graphviz gsm gstreamer gtk gtkhtml hal hddtemp humanities iceweasel iconv idea idn ieee1394 ilbc imlib immqt-bc injection iplsrc ipv6 isdnlog jabber jadetex jai java javascript jbig jikes jingle jmf jpeg jpeg2k jrtplib kerberos kpathsea ladspa laptop latex lcms ldap libcaca libgda libnotify loudmouth lua lyx m17n-lib mad math md5sum memlimit midi mikmod mmap mmx mng modplug motif mozcalendar mozdevelop mozilla mozsvg mozxmlterm mp2 mp3 mpeg mplayer msn mudflap musepack music mysql ncurses neXt nemesi network nls nntp nodrm nptl nptlonly nsplugin odbc offensive ogg omega openexr opengl openmp ortp oss ots pam pcmcia pcre pdf perl plotutils png pnm portaudio posix pppd profile pstricks publishers python qt3support quicktime radio rar readline real reflection rss science sdl session sid simplexml slang slp smi sndfile soap sockets socks5 sofia-sip speex spell spl srp srt srv sse sse2 ssl ssse3 startup-notification svg t1lib tcltk tcpd tex4ht theora thesaurus threads tiff timidity tk tokenizer tordns truetype tta unicode utils vcd verse vidix vim-syntax vorbis wavpack wifi win32codecs wma wmf wordperfect x264 x86 xcb xchatnogtk xetex xgetdefault xml xml2 xorg xsl xv xvid yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
The bad behavior only seems to occur with the -i flag on. Tried without the -i flag and for some reason it is emerging alot fewer packages. This is worrisome, as it only seems to want to emerge 7 packages now, whereas with the -i flag set it wants to emerge something on the order of 100 packages, 16 of which require ACCEPT_KEYWORDS="~x86" in order to emerge without downgrading (and which I've already taken care of but - python-updater doesn't get it with the -i flag set). So what happened to the other 80 or 90-odd packages? Why should it behave so differently with the -i flag set? I'm running a copy of python-updater right now with an augmented PKGS_EXCEPTIONS, and without the -i flag, because some of the packages had trouble emerging. When that finishes I'll rerun it with -i and see if anything changes.
You shouldn't be emerging with ACCEPT_KEYWORDS="~x86". If you need to unmask certain (versions of) packages, then add lines to /etc/portage/package.keywords. Here's an example (although I'm on amd64): =dev-db/mysql-gui-tools-5.0_p12-r2 ~amd64 x11-plugins/lightning ~amd64
That's true I suppose, but I'd rather not do it that way, because when the package becomes stable I want it to stay with that version or a later stable version, rather than automatically updating to the ~x86 version. If I use the unstable version of a package, I usually have a good reason for wanting that particular version of the package, I don't just love to have packages on my system that are unstable. So if I need to remerge something, I do not want my system to grab the unstable version even if there is a stable version available that is as new or newer than the one I have installed. In any case, there shouldn't be any reason why python-updater should automatically try to downgrade packages even if they are properly linked against python-2.5. If I had these packages in my packages.keywords file, it probably wouldn't be doing this (I was wrong about the -i option having anything to do with it, I subsequently found out), but it shouldn't be doing this either way. If it didn't even look at unstable packages without ACCEPT_KEYWORDS="~x86" on, then it would be okay - I'd just run it twice, first without ACCEPT_KEYWORDS="~x86", and then with (I'm not suggesting it should be designed that way, that would be pretty silly I think). But it seems to be looking for the unstable packages intentionally, and trying to downgrade them and remerge all their dependencies just to piss me off. I've got them all properly linked, so now it should just leave me alone. Anyways, I'll try with an augmented sham copy of my packages.keywords file, and let you know how it turns out. If it works, then I think that means something needs to be changed in python-updater, unless it just cannot do it's job without this bug.
Please reopen this bug report when there is an actual bug to report on - so far you have explained why the tools don't fit the job, where the job is apparently keeping half your system up to date and leaving the other half to bitrot in forgotten corners until tools fit to update an otherwise up to date system come round and show you the state your system is in. If you cannot be bothered to manage /etc/portage/package.{use,keywords,mask,unmask} for those cases where you want to emerge an exceptional version of a package, you probably shouldn't bother updating at all, ever.
(In reply to comment #7) > Please reopen this bug report when there is an actual bug to report on - so far > you have explained why the tools don't fit the job, where the job is apparently > keeping half your system up to date and leaving the other half to bitrot in > forgotten corners until tools fit to update an otherwise up to date system come > round and show you the state your system is in. I did not leave the other half to 'bitrot', I hand-emerged them. And I don't have 'half' my system unstable, just a small portion - but clearly enough to choke python-updater (which, neither one nor a thousand ~x86 packages not in the packages.keywords file ought to choke python-updater, if they are already up-to-date in terms of their linking against python). And your argument is the quintessential 'straw man argument'. I would in fact prefer to keep my entire system up to date, but that includes the possibility of me hand remerging a few packages that I emerged in an 'unsupported' manner and then python-updater not pretending like they are linked against the old python, which they clearly are not. And my system is now in a fine and consistent state with respect to packages that require python, but python-updater does not know that. It should, that's part of it's job. If you cannot be bothered to > manage /etc/portage/package.{use,keywords,mask,unmask} for those cases where > you want to emerge an exceptional version of a package, you probably shouldn't > bother updating at all, ever. > I don't see how that follows Jeroen. And for the record, I do manage a package.keywords file. I have it fully categorized and commented, and I only use it for packages that I don't mind updating as ~x86 on a more long term basis. In the meantime, as long as python-updater chokes on packages that were emerged by ~x86 keywords and not present in the packages.keywords file, it has a bug.
(In reply to comment #8) > I don't see how that follows Jeroen. And for the record, I do manage a > package.keywords file. I have it fully categorized and commented, and I only > use it for packages that I don't mind updating as ~x86 on a more long term > basis. In the meantime, as long as python-updater chokes on packages that were > emerged by ~x86 keywords and not present in the packages.keywords file, it has > a bug. If you were to look at the code, you were to find that in actual fact python-updater simply calls the package manager at the point where package updates are to be resolved. So please tell us where and how does python-updated fail in this case. To answer your original question (which doesn't appear to have anything to do with reporting bugs so far) - one way to fix python upgrade bugs is to simply delete (rm -r /usr/lib/python-2.4) the entire problem and then run something like: # emerge -va1 $(qfile `/usr/lib/python-2.4/') # where app-portage/portage-utils is assumed to be installed. If that still suggests downgrading, it should probably suffice to revisit package.keywords.
(In reply to comment #6) > That's true I suppose, but I'd rather not do it that way, because when the > package becomes stable I want it to stay with that version or a later stable > version, rather than automatically updating to the ~x86 version. If I use the > unstable version of a package, I usually have a good reason for wanting that > particular version of the package, I don't just love to have packages on my > system that are unstable. So if I need to remerge something, I do not want my > system to grab the unstable version even if there is a stable version available > that is as new or newer than the one I have installed. echo "=category/package-4321 ~x86" >> /etc/portage/package.keywords where 4321 is the package you are confident about is safe. This way, you'll run one certain testing version of a package until a newer stable version is available.
