Bugzilla Bug 219369

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 an attachment (id=151177) [details]
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.