Emerge doesn't refresh with updated USE flags [SOLVED]

[neyuru]

(Example give with wine) Steps:

• Emerge virtual/wine (emerge virtual/wine)
• Update package.use file with virtual/wine staging
• Issue a emerge -aDNuv @world (wine updates accordingly)
• Unmerge virtual/wine (emerge -c virtual/wine)
• Remerge virtual/wine (emerge virtual/wine)

Expected results: virtual/wine reinstalls with USE=staging as the package.use file hasn't been changed
Actual results: virtual/wine reinstalls with USE=-staging

What I am doing wrong?

thanks for the help.

[fedeliallalinea]

You are in a stable system?
If yes staging use flag is masked, so second case is normal because you should unmask it with /etc/portage/profile/package.use.mask but I don't understand because in first case works.

[neyuru]

You are in a stable system?

I think so. Other than a few packages with ~amd64 enabled (such as the kernel), system-wide I only have amd64:

Code: Select all

emerge --info wine
Portage 3.0.9 (python 3.8.6-final-0, default/linux/amd64/17.1/systemd, gcc-9.3.0, glibc-2.32-r3, 5.10.4-gentoo x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-5.10.4-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E3-1285_v4_@_3.50GHz-with-glibc2.2.5
KiB Mem:    32730440 total,  25452960 free
KiB Swap:    8389628 total,   8389628 free
Timestamp of repository gentoo: Thu, 31 Dec 2020 21:30:01 +0000
Head commit of repository gentoo: 58462db8f600e9f2a120cbc7e5664573f5326dc3
sh bash 5.0_p18
ld GNU ld (Gentoo 2.34 p6) 2.34.0
ccache version 4.1 [enabled]
app-shells/bash:          5.0_p18::gentoo
dev-java/java-config:     2.3.1::gentoo
dev-lang/perl:            5.30.3::gentoo
dev-lang/python:          3.8.6::gentoo, 3.9.0::gentoo
dev-util/ccache:          4.1::gentoo
dev-util/cmake:           3.17.4-r1::gentoo
sys-apps/baselayout:      2.7::gentoo
sys-apps/sandbox:         2.20::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:       1.16.2-r1::gentoo
sys-devel/binutils:       2.34-r2::gentoo
sys-devel/gcc:            9.3.0-r2::gentoo
sys-devel/gcc-config:     2.3.2-r1::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.3::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.32-r3::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    sync-rsync-verify-max-age: 24
    sync-rsync-extra-opts: 
    sync-rsync-verify-metamanifest: yes
    sync-rsync-verify-jobs: 1

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O3 -pipe -ggdb"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O3 -pipe -ggdb"
DISTDIR="/var/cache/distfiles"
EMERGE_DEFAULT_OPTS=" --jobs=8 --load-average=7.8"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-march=native -O3 -pipe -ggdb"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news nostrip parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-march=native -O3 -pipe -ggdb"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j8"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac acl acpi alsa amd64 branding bzip2 caps cdda cli colord crypt cuda cups dbus djvu dri dts dvd dvdr encode eselect-ldso exif ffmpeg fftw flac fortran gdbm gif gmp gnome-keyring gnutls gphoto2 gpm gtk gtk3 gui iconv icu introspection ipv6 jack jpeg jpeg2k lcms libcaca libglvnd libnotify libressl libsamplerate libtirpc lto lzma lzo mad matroska mp3 mp4 mpeg multilib ncurses networkmanager nls nptl nss nvenc ogg opencl opengl openmp pam pcre pdf pgo png policykit postscript ppds pulseaudio quicktime raw readline sdl seccomp spell split-usr ssl startup-notification svg systemd tcpd teamd threads tiff truetype udev udisks unicode upower usb v4l vaapi vdpau vorbis wavpack x264 xattr xcb xfce xml xv xvid zip zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="hda_intel ca0132" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd 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 cgi cgid 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" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput" KERNEL="linux" L10N="en es la" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2 php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python2_7 python3_8" RUBY_TARGETS="ruby25 ruby26" USERLAND="GNU" VIDEO_CARDS="nvidia intel iris" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS

=================================================================
                        Package Settings
=================================================================

virtual/wine-0-r7::gentoo was built with the following:
USE="(-staging)" ABI_X86="32 64"

[neyuru]

A related problem is the following:

When installed for the first time, wine demanded 100+ packages to be reinstalled with 32bit support, which is expected. When I then "upgraded" wine to "staging" another 10+ or so packages where also required to have support for 32bit. I am expecting that after reinstalling wine with USE=-staging (no staging support) then, all of these 10+ packages have to be reverted back to 64bit only, that is to be reinstalled in the state they where before the "staging" update. So, currently, there is no way to revert changes made to package.zz-autounmask if for some reason the user reverts from staging to no staging. At least, this is the impression I get as I don't remember which packages needed to be reinstalled in the last staging update. I cannot confirm they havn't been reverted but definitely, portage has not tell me until now (after several emerge -aDNuv @world) that any package would be reinstalled from (32 64) to only (64).

Maybe the answer lies in me not being able to use correctly emerge but, the same happens when I uninstall wine (emerge -c wine) and none of the initial 100+ packages are being "reverted" back to 64bit only after a emerge -aDNuv @world

[Hu]

That is not a problem. Wine with staging required the extra 32-bit support. Wine without staging or no-Wine has no opinion on the extra 32-bit support. You may remove it without complaint from Portage, or you may leave it. Wine does not require you to remove it, so Portage says nothing. Leaving it may be useful if you think you would reactivate Wine with staging at a later time.

[neyuru]

That is not a problem. Wine with staging required the extra 32-bit support. Wine without staging or no-Wine has no opinion on the extra 32-bit support. You may remove it without complaint from Portage, or you may leave it. Wine does not require you to remove it, so Portage says nothing. Leaving it may be useful if you think you would reactivate Wine with staging at a later time.

I do plan on having wine installed (with or without staging support) in the foreseeable future. Having said that, being Gentoo one of the most (if not, the most) configurable distro available, I am having trouble accepting that a user enforced change (compiling 100+ packages with 32bit support) cannot be reverted, in the same "easy" way as this change was done. Should a user (not me, but anyone) change its mind about having a package installed (wine is just the example), he should be able to revert the system to "a state before the package was installed". Meaning, (in this context) if a installed package requires enabling keywords for other packages (in this example abi_x86_32 for 100+ packages) and if portage does that work for you (asking for your permission to edit zz-autonmask e.g. for the 100+ packages) then, if the user so wishes, he may unmerge the original package and be given the option* to keep 32bit support for the 100 packages. Otherwise, if this support is not needed, why would anyone keep it? Does the user have to manually revert for each package? (assuming he kept a record of the changed packages.)

*In my opinion this should be a feature, being the default action to revert all changes enforced by the installation of this package, granted, other packages don't require a subset of these changes.

[Hu]

It is easy to revert. Delete the lines that you added.

As I said, a user might choose to keep the change because he expects it to be useful again in the future.

[neyuru]

Hi:

Deleting the line:

Code: Select all

virtual/wine staging

in package.use does nothing. By nothing I mean undoing the 100+ package updates with support for 32bit. This is the last problem I mentioned. As for the OP, placing again the above line (after deleting it and issuing a emerge -aDNuv @world) does not make portage aware of the change so that it can re-emerge it with support for only 64 bit. It must be noted that portage did update wine when placing the line in portage for the first time. This does no longer work. I cannot find a way to tell portage to update wine again to "staging".

I understand what you're saying about the probable usefulness in the future about leaving the 32bit support, even when it's not needed now. But my point is, if the user does no longer needs/require this support, ever, then it will be a waste of time in the life of the system as these packages need to be installed in both 32 and 64 bit support when compiling in future updates. So the conundrum is this: leave the support for 32 bit in the possible case in the future it will be needed (and compiling the packages every future update) or recompiling now and only recompiling again when they are needed. The answer may lie in the probability of these packages being needed again. This probability could only be given by the user of the system, hence my concern. Or am I wrong?

[Hu]

Did you reinstall virtual/wine after that change, and did Portage show that it now has USE=-staging? If so, then it did what is expected. With that change, it no longer depends on app-emulation/wine-staging[staging], so now Portage will allow you to set USE=-staging on app-emulation/wine-staging, or even remove that entirely and use app-emulation/wine-vanilla.

Switching off wine-staging is not expected to influence 32/64 bit mode. For that, you need to adjust the abi_x86 flags. You are correct that Portage does not offer a straightforward mechanism to change the flag, and then defer acting on that change until you have some other reason to update the package. You could disable it now and choose not to reinstall the package until an upgrade is available.

[neyuru]

Long story short, the issue is resolved. As fedeliallalinea pointed out, unmasking this package (along with other dependencies) solved the issue. However, there was some behaviour that confused my little brainZ. If interested keep reading.

The reason I did not immediately unmask wine was because, as mentioned in the first post, the -unmasked- package did react to a change in package.use when I placed the staging USE flag. And, above all, it did "update"**. In my tiny experience as a gentoo user, this in contrast where most, if not all packages that the user somehow requests and that are masked by the ~amd64 keyword, do tell portage that they need to be unmasked before isntallation. In this case as staging is a masked feature and I enabled it through package.use, portage did not warn me to unmask wine. This was the most confusing part and the reason I was at first adamant to unmask it was because I thought the problem was elsewhere. I will be flagging this as resolved because now that wine is unmasked it immediately reacts to a change in package.use.

As for the secondary problem, it could be great if somehow portage keeps a watchful eye in 32-64 bit dependencies as it does in package dependencies. It would be great if it had a feature to remove unneeded 32 bit dependencies just like unneeded packages dependencies, (e.g. emerge --depclean)

Thank you all for the rapid and precise support!


**NOTE when I first installed wine a bunch of packages required a change to the 32bit word and when staging was requested, another bunch of packages did request an update to 32bit as well. In my innocence, this lead me to believe that indeed the update was successful. Little did I knew that eselect only had vanilla wine untiil this point.