Hello, Could not find a bug report of this. When removing the none stable keyword from /etc/portage/package.keywords, previous versions of portage installed the last stable version after: emerge --update --deep world Current portage does not do so: # emerge --update --deep --newuse --pretend world <nothing> # equery list genkernel [I--] [M~] sys-kernel/genkernel-3.4.10_pre10 (0) genkernel should have been reemerged stable. Any clue? Portage 2.1.5_rc6 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.7-r2, 2.6.25-gentoo i686) ================================================================= System uname: 2.6.25-gentoo i686 Intel(R) Pentium(R) M processor 1.80GHz Timestamp of tree: Sat, 26 Apr 2008 01:45:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.2.2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 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="-O3 -march=pentium-m -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/4.0/env /usr/kde/4.0/share/config /usr/kde/4.0/shutdown /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O3 -march=pentium-m -fomit-frame-pointer -pipe" DISTDIR="/var/gentoo/distfiles" FEATURES="autoaddcvs cvs distlocks parallel-fetch sandbox sfperms strict unmerge-orphans userfetch userpriv usersandbox webrsync-gpg" GENTOO_MIRRORS="http://mirror.hamakor.org.il/pub/mirrors/gentoo http://gentoo.osuosl.org" LANG="he_IL.UTF-8" LDFLAGS="" LINGUAS="en he" MAKEOPTS="-j2" PKGDIR="/var/gentoo/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/local/portage/local /usr/local/portage/alon-barlev-portage /usr/local/portage/ase /usr/portage/local/layman/java-gcj-overlay /usr/portage/local/layman/wschlich-testing" SYNC="" USE="X aac acl acpi alsa apache2 arts audit bidi bluetooth bzip2 cairo caps cdr cli cracklib crypt cups curl dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox gcj gif gpm gstreamer gtk iconv ipv6 isdnlog jpeg jpeg2k kde kdeenablefinal kerberos ldap logrotate mad midi mikmod mmx mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp pam pcre pdf plasma png pppd qt3 qt3support qt4 readline reflection samba sdl session smartcard spell spl sse sse2 ssl svg tcpd tiff truetype unicode vim-syntax vorbis wifi x86 xcomposite xinerama xml xorg xv zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_anon authn_default authn_file authz_default authz_groupfile authz_host authz_user dav dir env expires mime" APACHE2_MPMS="prefork" CAMERAS="canon ptp2" ELIBC="glibc" INPUT_DEVICES="mouse keyboard evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en he" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
It needs to be taught to recognize the specific case where the installed package is masked by KEYWORDS and there is an available downgrade to a version with visible KEYWORDS (current behavior is to completely ignore KEYWORDS of installed packages).
In the past it worked, right?
Yes, it used to work, but the package selection logic has changed a lot since then.
Created attachment 151177 [details, diff] enable upgrage or downgrade to a different version with visible KEYWORDS I think this will satisfy our needs. Does it work for you?
Yes, thanks!
I'm seeing the same problem with pygtk-2.12.1 which was marked -amd64 after it got installed with ~amd64. When do we expect the patch in a released version of portage?
2.1.5_rc7 is almost ready. Should be released sometime in the next 24 hours.
This is fixed in 2.1.5_rc7.
I believe one more issue exists. I just found out that I had keyutils installed, this package has no stable keyword, and downgrade/block/note was not presented. Maybe a note regarding this should be displayed during emerge --update --deep world, instead of ignoring this state? Thanks! # equery list keyutils [ Searching for package 'keyutils' in all categories among: ] * installed packages [I--] [M~] sys-apps/keyutils-1.2 (0)
(In reply to comment #9) > I believe one more issue exists. > > I just found out that I had keyutils installed, this package has no stable > keyword, and downgrade/block/note was not presented. > > Maybe a note regarding this should be displayed during emerge --update --deep > world, instead of ignoring this state? > > Thanks! > > # equery list keyutils > [ Searching for package 'keyutils' in all categories among: ] > * installed packages > [I--] [M~] sys-apps/keyutils-1.2 (0) > I'd like to be more strict about installed packages that are keyword masked, however it's a tricky situation. Older versions of portage didn't create /var/db/pkg/*/*/KEYWORDS entries, and many users still have old packages installed that are missing these entries. Also, as evidenced by bug 209538 and bug 220689, many users seem to have keyword masked packages installed for various reasons. I suppose the we could add some option or feature to enable stricter keywords checking for installed packages, but it is nicer if we can use some sort of algorithm to identify specific cases that all users should be warned about.
(In reply to comment #10) > I suppose the we could add some option or feature to enable stricter keywords > checking for installed packages, but it is nicer if we can use some sort of > algorithm to identify specific cases that all users should be warned about. Perhaps an emaint check will satisfy your needs?
No. I ran emaint and nothing to be fixed. Still keyutils is installed as some package depended on it. # equery depends keyutils [ Searching for packages depending on keyutils... ] sys-fs/ecryptfs-utils-42 (>=sys-apps/keyutils-1.0) So I don't have ~x86 in package.keywords, I have this installed, all is find, but it should not be installed, or at least warn, right?
(In reply to comment #12) > No. > I ran emaint and nothing to be fixed. You've misunderstood me, I was suggesting a new emaint check that hasn't been implemented yet. Keywords for sys-apps/keyutils: | a a a h i m m p p s s s s x x | l m r p a 6 i p p 3 h p p 8 8 | p d m p 6 8 p c c 9 a a 6 6 | h 6 a 4 k s 6 0 r r - | a 4 4 c c f | - b | f s | b d | s | d ----+------------------------------ 1.0 | ~ 1.1 | ~ ~ ~ 1.2 | ~ ~ ~ ~ ~ ~ ~ ~ The keywords seem to imply that you had accepted the keywords when you installed the package. Do you not accept them now for some reason? If not, then the behavior that you want seems to differ from the user who filed bug 209538. For example, we know that lots of users have done things like this: env ACCEPT_KEYWORDS=~x86 emmerge ecryptfs-utils Obviously, users who have done something like that do not want to receive a bunch of warnings that they don't care about. So, the behavior needs to be configurable.
OK! Now I understand the confusion... USE="doc" emerge whatever emerge --update --deep --newuse world The manual doc is gone... right? As the user did not add this to the /etc/portage/package.use. The same should be with keywords ACCEPT_KEYWORDS="~x86" emerge whatever emerge --update --deep Should revert to stable or delete/warn as user did not add this to persistence definition /etc/portage/package.keywords. Why do you think there should be a difference between the two cases?
(In reply to comment #14) > Why do you think there should be a difference between the two cases? Remember that the "revert to stable" thing is already implemented (that's what this bug was about, but it happens that keyutils has not stable version to revert to). Personally, I don't think there should be an difference. However, there are a couple of issues: 1) Some users, like the one who filed bug #209538, will probably complain about warning messages. I'd advise them all to use autounmask, but if a change like this is too unpopular then it results in lots of noise from users, which makes the change counterproductive for portage devs like me (noise == lost time). 2) Even people who do the right thing and use autounmask are still quite likely to have missing /var/db/pkg/*/*/KEYWORDS files for packages that were installed by old versions of portage. We can implement a new emaint task that will create the missing files, so that's certainly solvable. So, the main hurdle for me is (1) since it involves changing the behavior of a potentially large portion of our user base. Sure, they should all be using autounmask, but I really don't want to deal with a whole lot of noise and the lost time that comes with it. Besides, the only case where it will provide a benefit is the case in which there is no stable version to revert to, which seems like a nearly negligible corner case.
Thinking a little more, one case that we could easily warn about without bothering people is the case when the installed version is masked by keywords and it's not upgraded to a newer version with identical keywords. For example, suppose that you have keyutils-1.0 installed and it's masked by keywords. It won't "revert to stable" because there is no stable version. However, it also won't upgrade to keyutils-1.2 if you haven't accepted the keywords. That's one case that I think we could warn about without upsetting too many people.
Well... I think that being consistent is more important. emerge --update --deep --newuse world Should return to the persistant state. Maybe the important of consistent behavior which should be better explained to users, as you cannot trust system integrity any other way. But the last solution you come up with will provide some control, however, I don't think it is the right one.
I'll revisit the idea of adding an additional warning in the future, but it's just not worth the trouble for me at this time.
