[gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

[Thomas Deutschmann]

Hi,

it is currently not possible to smoothly run a world upgrade on a 4
months old system which doesn't even have a complicated package list:

> # cat /var/lib/portage/world
> app-admin/eclean-kernel
> app-admin/logrotate
> app-admin/rsyslog
> app-editors/nano
> app-misc/ca-certificates
> app-misc/colordiff
> app-misc/mc
> app-misc/tmux
> app-portage/cpuid2cpuflags
> app-portage/eix
> app-portage/elogv
> app-portage/genlop
> app-portage/gentoolkit
> app-portage/pfl
> app-portage/portage-utils
> app-portage/repoman
> app-portage/smart-live-rebuild
> app-portage/tatt
> app-shells/bash-completion
> app-shells/gentoo-bashcomp
> app-text/ansifilter
> app-text/tree
> app-text/wgetpaste
> dev-util/ccache
> dev-util/strace
> dev-util/valgrind
> dev-vcs/git
> net-analyzer/tcpdump
> net-dns/bind-tools
> net-misc/dhcpcd
> net-misc/ntp
> sys-apps/gptfdisk
> sys-apps/haveged
> sys-apps/iproute2
> sys-apps/less
> sys-apps/mlocate
> sys-apps/pciutils
> sys-apps/portage
> sys-boot/grub
> sys-devel/gdb
> sys-fs/ncdu
> sys-kernel/dracut
> sys-kernel/genkernel
> sys-kernel/gentoo-sources
> sys-process/fcron
> sys-process/htop
> sys-process/iotop

When you try to upgrade world, it will fail with:

> # emerge --ask --verbose --update --deep --tree --changed-deps=y --with-bdeps=y --newrepo --keep-going=y
> --backtrack=100 --newuse --verbose-conflicts world
>
> * IMPORTANT: 2 news items need reading for repository 'gentoo'.
> * Use eselect news read to view new items.
>
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
>
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> dev-lang/perl:0
>
> (dev-lang/perl-5.34.0-r3:0/5.34::gentoo, ebuild scheduled for merge) USE="gdbm ithreads -berkdb -debug -doc -minimal" pulled in by
> (no parents that aren't satisfied by other packages in this slot)
>
> (dev-lang/perl-5.32.1-1:0/5.32::gentoo, installed) USE="berkdb gdbm ithreads -debug -doc -minimal" pulled in by
> dev-lang/perl:0/5.32=[-build(-)] required by (dev-perl/IO-HTML-1.1.0-2:0/0::gentoo, installed) USE="-test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Try-Tiny-0.300.0-2:0/0::gentoo, installed) USE="-minimal -test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Authen-SASL-2.160.0-r2-2:0/0::gentoo, installed) USE="-kerberos -test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Mozilla-CA-20999999-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/IO-Socket-INET6-2.720.0-r1-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/WWW-RobotRules-6.20.0-r1-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Socket6-0.280.0-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32=[-build(-)] required by (dev-perl/LWP-MediaTypes-6.20.0-r1-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/TimeDate-2.330.0-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Module-Build-0.422.400-2:0/0::gentoo, installed) USE="-test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/HTTP-Negotiate-6.10.0-r1-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/IO-Socket-SSL-2.66.0-2:0/0::gentoo, installed) USE="idn -examples"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Locale-gettext-1.70.0-2:0/0::gentoo, installed) USE=""
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Encode-Locale-1.50.0-2:0/0::gentoo, installed) USE="-test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/MailTools-2.190.0-2:0/0::gentoo, installed) USE="-examples -test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/LWP-Protocol-https-6.70.0-2:0/0::gentoo, installed) USE="-test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/URI-1.730.0-2:0/0::gentoo, installed) USE="-test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/Net-SSLeay-1.880.0-r1-2:0/0::gentoo, installed) USE="-examples -minimal -test"
> ^^^^^^^^
> dev-lang/perl:0/5.32= required by (dev-perl/HTTP-Message-6.130.0-2:0/0::gentoo, installed) USE="-test"
> ^^^^^^^^
>
>
> !!! The slot conflict(s) shown above involve package(s) which may need to
> !!! be rebuilt in order to solve the conflict(s). However, the following
> !!! package(s) cannot be rebuilt for the reason(s) shown:
>
> (dev-perl/HTTP-Negotiate-6.10.0-r1-2:0/0::gentoo, installed): ebuild is masked or unavailable
> (dev-perl/IO-HTML-1.1.0-2:0/0::gentoo, installed): ebuild is masked or unavailable
> (dev-perl/WWW-RobotRules-6.20.0-r1-2:0/0::gentoo, installed): ebuild is masked or unavailable
> (dev-perl/HTTP-Message-6.130.0-2:0/0::gentoo, installed): ebuild is masked or unavailable
> (dev-perl/Encode-Locale-1.50.0-2:0/0::gentoo, installed): ebuild is masked or unavailable
> (dev-perl/TimeDate-2.330.0-2:0/0::gentoo, installed): ebuild is masked or unavailable
> (dev-perl/Try-Tiny-0.300.0-2:0/0::gentoo, installed): ebuild is masked or unavailable
>
>
> It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously. If such a conflict exists in
> the dependencies of two different packages, then those packages can
> not be installed simultaneously.
>
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.
>
>
> emerge: there are no ebuilds built with USE flags to satisfy "app-portage/nattka[python_targets_python3_8(-)?,python_targets_python3_9(-)?]".
> !!! One of the following packages is required to complete your request:
> - app-portage/nattka-0.2.12::gentoo (Change USE: +python_targets_python3_9)
> - app-portage/tatt-9999::gentoo (Change USE: -python_targets_python3_9, this change violates use flag constraints defined by app-portage/tatt-9999: 'any-of ( python_targets_python3_8 python_targets_python3_9 )')
> (dependency required by "app-portage/tatt-9999::gentoo" [ebuild])
> (dependency required by "@selected" [set])
> (dependency required by "@world" [argument])

Just trying to upgrade portage will fail like:

> # emerge -a1 portage
>
> * IMPORTANT: 2 news items need reading for repository 'gentoo'.
> * Use eselect news read to view new items.
>
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] dev-python/certifi-10001-r1::gentoo USE="-test" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 0 KiB
> [ebuild U ] dev-python/setuptools-57.5.0::gentoo [56.0.0::gentoo] USE="-test" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 2,100 KiB
> [ebuild N ] dev-python/tomli-1.2.1::gentoo USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" 120 KiB
> [ebuild N ] dev-python/pyparsing-2.4.7-r1::gentoo USE="-examples" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" 633 KiB
> [ebuild N ] dev-python/packaging-21.0::gentoo USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" 79 KiB
> [ebuild U ] dev-python/setuptools_scm-6.3.2::gentoo [6.0.1-r1::gentoo] USE="-test" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 56 KiB
> [ebuild N ] dev-python/charset_normalizer-2.0.6::gentoo USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" 360 KiB
> [ebuild U ] dev-python/idna-3.2::gentoo [3.1::gentoo] PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 239 KiB
> [ebuild R ] dev-python/PySocks-1.7.1-r1::gentoo PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 0 KiB
> [ebuild U ] dev-python/urllib3-1.26.7::gentoo [1.26.4::gentoo] USE="-brotli -test" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 285 KiB
> [ebuild U ] dev-python/requests-2.26.0::gentoo [2.25.1-r2::gentoo] USE="-socks5 -test" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 102 KiB
> [ebuild R ] app-portage/gemato-16.2::gentoo USE="gpg -test -tools" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 0 KiB
> [ebuild U ] sys-apps/portage-3.0.20-r6::gentoo [3.0.18::gentoo] USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_9* (-pypy3) (-python3_10) -python3_8* (-python3_7%)" 1,337 KiB
>
> Total: 13 packages (6 upgrades, 4 new, 3 reinstalls), Size of downloads: 5,308 KiB
>
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> sys-apps/portage:0
>
> (sys-apps/portage-3.0.20-r6:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> sys-apps/portage (Argument)
>
> (sys-apps/portage-3.0.18-1:0/0::gentoo, installed) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9" pulled in by
> sys-apps/portage[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (app-portage/gentoolkit-0.5.1-1:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
> sys-apps/portage[python_targets_python3_8(-)?,python_targets_python3_9(-)?] required by (app-portage/pfl-3.1-r1-3:0/0::gentoo, installed) USE="-network-cron" PYTHON_TARGETS="python3_8 -python3_7 -python3_9"
>
> sys-apps/portage[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (app-portage/elogv-0.7.9-1:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
> >=sys-apps/portage-3.0.4[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?] required by (app-portage/repoman-3.0.2-2:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
>
> app-portage/gemato:0
>
> (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for merge) USE="gpg -test -tools" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> >=app-portage/gemato-14.5[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (sys-apps/portage-3.0.20-r6:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (app-portage/gemato-16.2-2:0/0::gentoo, installed) USE="gpg -test -tools" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9" pulled in by
> >=app-portage/gemato-14.5[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?] required by (sys-apps/portage-3.0.18-1:0/0::gentoo, installed) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
>
> dev-python/requests:0
>
> (dev-python/requests-2.26.0:0/0::gentoo, ebuild scheduled for merge) USE="-socks5 -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for merge) USE="gpg -test -tools" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/requests-2.25.1-r2-2:0/0::gentoo, installed) USE="-socks5 -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9" pulled in by
> dev-python/requests[python_targets_python3_8(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (app-portage/nattka-0.2.12-1:0/0::gentoo, installed) USE="-depgraph-order -doc -test" PYTHON_TARGETS="python3_8 -python3_9"
>
> dev-python/requests[python_targets_python3_8(-)?,python_targets_python3_9(-)?] required by (app-portage/pfl-3.1-r1-3:0/0::gentoo, installed) USE="-network-cron" PYTHON_TARGETS="python3_8 -python3_7 -python3_9"
>
> dev-python/requests[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (app-portage/gemato-16.2-2:0/0::gentoo, installed) USE="gpg -test -tools" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
> dev-python/requests[python_targets_python3_8(-)?,python_targets_python3_9(-)?] required by (app-portage/tatt-9999-7:0/0::gentoo, installed) USE="templates" PYTHON_TARGETS="python3_8 -python3_9"
>
>
> dev-python/urllib3:0
>
> (dev-python/urllib3-1.26.7:0/0::gentoo, ebuild scheduled for merge) USE="-brotli -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> <dev-python/urllib3-1.27[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.26.0:0/0::gentoo, ebuild scheduled for merge) USE="-socks5 -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/urllib3-1.26.4-3:0/0::gentoo, installed) USE="-brotli -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9" pulled in by
> <dev-python/urllib3-1.27[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.25.1-r2-2:0/0::gentoo, installed) USE="-socks5 -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
>
> dev-python/PySocks:0
>
> (dev-python/PySocks-1.7.1-r1:0/0::gentoo, ebuild scheduled for merge) USE="" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> <dev-python/PySocks-2.0[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/urllib3-1.26.7:0/0::gentoo, ebuild scheduled for merge) USE="-brotli -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/PySocks-1.5.8[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/urllib3-1.26.7:0/0::gentoo, ebuild scheduled for merge) USE="-brotli -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/PySocks-1.7.1-r1-4:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9" pulled in by
> >=dev-python/PySocks-1.5.8[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-),-python_single_target_python3_10(-)] required by (dev-python/urllib3-1.26.4-3:0/0::gentoo, installed) USE="-brotli -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> <dev-python/PySocks-2.0[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-),-python_single_target_python3_10(-)] required by (dev-python/urllib3-1.26.4-3:0/0::gentoo, installed) USE="-brotli -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
>
> dev-python/idna:0
>
> (dev-python/idna-3.2:0/0::gentoo, ebuild scheduled for merge) USE="" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> <dev-python/idna-4[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.26.0:0/0::gentoo, ebuild scheduled for merge) USE="-socks5 -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/idna-3.1-1:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9" pulled in by
> >=dev-python/idna-2.5[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.25.1-r2-2:0/0::gentoo, installed) USE="-socks5 -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> <dev-python/idna-4[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.25.1-r2-2:0/0::gentoo, installed) USE="-socks5 -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
>
> dev-python/certifi:0
>
> (dev-python/certifi-10001-r1:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> >=dev-python/certifi-2016.9.26[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/setuptools-57.5.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/certifi-2017.4.17[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.26.0:0/0::gentoo, ebuild scheduled for merge) USE="-socks5 -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/certifi-10001-r1-6:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9" pulled in by
> >=dev-python/certifi-2016.9.26[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/setuptools-56.0.0-1:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
> >=dev-python/certifi-2017.4.17[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.25.1-r2-2:0/0::gentoo, installed) USE="-socks5 -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
>
> dev-python/setuptools:0
>
> (dev-python/setuptools-57.5.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (sys-apps/portage-3.0.20-r6:0/0::gentoo, ebuild scheduled for merge) USE="(ipc) native-extensions rsync-verify xattr -apidoc -build -doc -gentoo-dev (-selinux) -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.26.0:0/0::gentoo, ebuild scheduled for merge) USE="-socks5 -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/PySocks-1.7.1-r1:0/0::gentoo, ebuild scheduled for merge) USE="" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/setuptools_scm-6.3.2:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/idna-3.2:0/0::gentoo, ebuild scheduled for merge) USE="" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/charset_normalizer-2.0.6:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/tomli-1.2.1:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/pyparsing-2.4.7-r1:0/0::gentoo, ebuild scheduled for merge) USE="-examples" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/packaging-21.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (app-portage/gemato-16.2:0/0::gentoo, ebuild scheduled for merge) USE="gpg -test -tools" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/urllib3-1.26.7:0/0::gentoo, ebuild scheduled for merge) USE="-brotli -test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/setuptools-56.0.0-1:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9" pulled in by
> >=dev-python/setuptools-42.0.2[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-),-python_single_target_python3_10(-)] required by (dev-python/idna-3.1-1:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_python3_8(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-util/meson-0.56.2-1:0/0::gentoo, installed) USE="(-test)" PYTHON_TARGETS="python3_8 -python3_7 -python3_9"
>
> dev-python/setuptools[python_targets_python3_8(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (www-client/pybugz-0.13-2:0/0::gentoo, installed) USE="-zsh-completion" PYTHON_TARGETS="python3_8 -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_python3_8(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (app-portage/nattka-0.2.12-1:0/0::gentoo, installed) USE="-depgraph-order -doc -test" PYTHON_TARGETS="python3_8 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-),-python_single_target_python3_10(-)] required by (dev-python/urllib3-1.26.4-3:0/0::gentoo, installed) USE="-brotli -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/PySocks-1.7.1-r1-4:0/0::gentoo, installed) USE="" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/setuptools_scm-6.0.1-r1-1:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/requests-2.25.1-r2-2:0/0::gentoo, installed) USE="-socks5 -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/cython-0.29.23-1:0/0::gentoo, installed) USE="-doc -emacs -test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/toml-0.10.2-3:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9"
>
> >=dev-python/setuptools-42.0.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (app-portage/gemato-16.2-2:0/0::gentoo, installed) USE="gpg -test -tools" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
>
> dev-python/setuptools_scm:0
>
> (dev-python/setuptools_scm-6.3.2:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8" pulled in by
> dev-python/setuptools_scm[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?] required by (dev-python/setuptools-57.5.0:0/0::gentoo, ebuild scheduled for merge) USE="-test" PYTHON_TARGETS="python3_9 (-pypy3) (-python3_10) -python3_8"
>
>
> (dev-python/setuptools_scm-6.0.1-r1-1:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) (-python3_10) -python3_7 -python3_9" pulled in by
> dev-python/setuptools_scm[python_targets_python3_8(-),-python_single_target_pypy3(-),-python_single_target_python3_7(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)] required by (dev-python/setuptools-56.0.0-1:0/0::gentoo, installed) USE="-test" PYTHON_TARGETS="python3_8 (-pypy3) -python3_7 -python3_9"
>
>
>
> It may be possible to solve this problem by using package.mask to
> prevent one of those packages from being selected. However, it is also
> possible that conflicting dependencies exist such that they are
> impossible to satisfy simultaneously. If such a conflict exists in
> the dependencies of two different packages, then those packages can
> not be installed simultaneously. You may want to try a larger value of
> the --backtrack option, such as --backtrack=30, in order to see if
> that will solve this conflict automatically.
>
> For more information, see MASKED PACKAGES section in the emerge man
> page or refer to the Gentoo Handbook.
>
>
> !!! The following installed packages are masked:
> - sys-devel/binutils-2.35.2::gentoo (masked by: package.mask)
> /var/db/repos/gentoo/profiles/package.mask:
> # Andreas K. Hüttel <dilf...@gentoo.org> (2017-05-21)
> # (and others, updated later)
> # These old versions of toolchain packages (binutils, gcc, glibc) are no
> # longer officially supported and are not suitable for general use. Using
> # these packages can result in build failures (and possible breakage) for
> # many packages, and may leave your system vulnerable to known security
> # exploits.
> # If you still use one of these old toolchain packages, please upgrade (and
> # switch the compiler / the binutils) ASAP. If you need them for a specific
> # (isolated) use case, feel free to unmask them on your system.
>
> - sys-libs/glibc-2.32-r7::gentoo (masked by: package.mask)
> - virtual/perl-Pod-Parser-1.630.0-r8::gentoo (masked by: package.mask)
> /var/db/repos/gentoo/profiles/package.mask:
> # Andreas K. Hüttel <dilf...@gentoo.org> (2021-10-16)
> # Outdated virtual; the respective module was removed
> # from core Perl with Perl 5.32. Use dev-perl/Pod-Parser
> # instead. Removal in 30days.
>
> For more information, see the MASKED PACKAGES section in the emerge
> man page or refer to the Gentoo Handbook.

Python:

> # grep -Fr TARGETS /etc/portage
> /etc/portage/make.d/PHP.conf:#PHP_TARGETS="php5-6 php7-0 php7-1 php7-2 php7-3"
> /etc/portage/make.d/RUBY.conf:#RUBY_TARGETS="ruby22 ruby23"
> /etc/portage/make.d/RUBY.conf:RUBY_TARGETS="ruby25 ruby26"
> /etc/portage/make.d/PYTHON.conf:#PYTHON_TARGETS="python2_7 python3_7"
> /etc/portage/make.d/PYTHON.conf:#PYTHON_TARGETS="python3_7 python3_8"
> # portageq envvar PYTHON_TARGETS
> python3_9
> # portageq envvar PYTHON_SINGLE_TARGET
> python3_9

(no packages are manually set to a different Python version)



This is not about finding solution to upgrade the system (in this case
it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
about raising awareness that Gentoo is a rolling distribution and that
we guarantee users to be able to upgrade their system when they do world
upgrades just once a year (remember: in my case the last world upgrade
is just 4 months old!). If they cannot upgrade their system without
manual intervention, we failed to do our job.

Situations like this will disqualify Gentoo for any professional
environment like this will break automatic upgrades and you cannot roll
individual fixes for each possible situation via CFM tools like Salt,
Ansible, Puppet or Chef.

It would be very appreciated if everyone will pay more attention to this
in future. We can do better. In most cases we can avoid problems like
this by keeping older ebuilds around much longer for certain key
packages to help with upgrades.

Thank you.


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

[Rich Freeman]

On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whi...@gentoo.org> wrote:
>
> This is not about finding solution to upgrade the system (in this case
> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
> about raising awareness that Gentoo is a rolling distribution and that
> we guarantee users to be able to upgrade their system when they do world
> upgrades just once a year (remember: in my case the last world upgrade
> is just 4 months old!). If they cannot upgrade their system without
> manual intervention, we failed to do our job.

Do we have this "guarantee" documented somewhere? I thought I've
heard six months tossed around. You say one year. It seems
reasonable to have some sort of guideline like this and try to stick
with it, at least for @system.

(I had a painful update on a container that was about six months old a
little while ago - I just did updates from git checkouts (which isn't
guaranteed to work due to distfiles issues). Obviously
troubleshooting a container where a rollback is a one-liner is a lot
easier, but progressive updates also tend to require a lot of
semi-redundant updates.)

--
Rich

[Ulrich Mueller]

>>>>> On Wed, 03 Nov 2021, Rich Freeman wrote:

> On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whi...@gentoo.org> wrote:
>>
>> This is not about finding solution to upgrade the system (in this case
>> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
>> about raising awareness that Gentoo is a rolling distribution and that
>> we guarantee users to be able to upgrade their system when they do world
>> upgrades just once a year (remember: in my case the last world upgrade
>> is just 4 months old!). If they cannot upgrade their system without
>> manual intervention, we failed to do our job.

> Do we have this "guarantee" documented somewhere? I thought I've
> heard six months tossed around. You say one year. It seems
> reasonable to have some sort of guideline like this and try to stick
> with it, at least for @system.

We do. Summary of 2009-11-09 Council meeting:

| https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
|
| Upgrade path for old systems
| ----------------------------
| Vote (unanimous): The ebuild tree must provide an upgrade path to a
| stable system that hasn't been updated for one year.
|
| Action: leio will start a discussion on gentoo-dev on if and how to
| support upgrading systems that are outdated more than a year.

[John Helmert III]

On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote:
> >>>>> On Wed, 03 Nov 2021, Rich Freeman wrote:
>
> > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whi...@gentoo.org> wrote:
> >>
> >> This is not about finding solution to upgrade the system (in this case
> >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
> >> about raising awareness that Gentoo is a rolling distribution and that
> >> we guarantee users to be able to upgrade their system when they do world
> >> upgrades just once a year (remember: in my case the last world upgrade
> >> is just 4 months old!). If they cannot upgrade their system without
> >> manual intervention, we failed to do our job.
>
> > Do we have this "guarantee" documented somewhere? I thought I've
> > heard six months tossed around. You say one year. It seems
> > reasonable to have some sort of guideline like this and try to stick
> > with it, at least for @system.
>
> We do. Summary of 2009-11-09 Council meeting:
>
> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
> |
> | Upgrade path for old systems
> | ----------------------------
> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> | stable system that hasn't been updated for one year.

Does "upgrade path" imply a simple world upgrade is all that should be
necessary to upgrade the system? I wouldn't interpret it this way.

[Thomas Deutschmann]

On 2021-11-03 17:44, John Helmert III wrote:
>> | Upgrade path for old systems
>> | ----------------------------
>> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
>> | stable system that hasn't been updated for one year.
> Does "upgrade path" imply a simple world upgrade is all that should be
> necessary to upgrade the system? I wouldn't interpret it this way.

Could you please share your interpretation? I wonder how you can agree
on an upgrade path but still require manually hacking to get a system
up-to-date. That is basically the definition of "upgrade path"...

[John Helmert III]

On Wed, Nov 03, 2021 at 05:51:49PM +0100, Thomas Deutschmann wrote:
> On 2021-11-03 17:44, John Helmert III wrote:
> >> | Upgrade path for old systems
> >> | ----------------------------
> >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> >> | stable system that hasn't been updated for one year.
> > Does "upgrade path" imply a simple world upgrade is all that should be
> > necessary to upgrade the system? I wouldn't interpret it this way.
>
> Could you please share your interpretation? I wonder how you can agree
> on an upgrade path but still require manually hacking to get a system
> up-to-date. That is basically the definition of "upgrade path"...

Sure. An "upgrade path" to me sounds like not just a world update, but
also includes other stuff that might be necessary to get a system
fully updated, like temporarily setting PYTHON_TARGETS to upgrade a
package.

A system without an upgrade path would seem to be a system where there
is no way to upgrade it without reinstalling, which you seem to be
asserting is the case for this system.

13:36 <@Whissi> Nice. Due to some people rushing to EAPI8 and remove old ebuilds they broke the guarantee to update systems at least once a year again. Congratulations! http://dpaste.com/AD87YKY62
13:36 <+sam_> your issue is to do with python targets changing: PYTHON_TARGETS="python3_8" emerge -v1 portage should work
13:37 <@Whissi> As you can see, it doesn't work.
13:37 <+sam_> that's not what you ran though?
13:37 <+sam_> see https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Upgrading_Portage#Solution
13:37 <@Whissi> http://dpaste.com/7RYRJD72H
13:38 <+sam_> you're not forcing the old PYTHON_TARGETS?
13:39 <@Whissi> No, http://dpaste.com/7V727USW4
13:39 <+sam_> but i'm saying you should
13:39 <+sam_> (not that you should _have_ to)
13:39 <+sam_> temporarily do it once on the command line
13:39 <+sam_> it is enough to get portage upgraded
13:39 <+sam_> we do it often in #gentoo

Based on this snippet from #gentoo-mozilla, it does seem like there is
a way forward for this system.

[Ulrich Mueller]

>>>>> On Wed, 03 Nov 2021, John Helmert wrote:

>> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
>> |
>> | Upgrade path for old systems
>> | ----------------------------
>> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
>> | stable system that hasn't been updated for one year.

> Does "upgrade path" imply a simple world upgrade is all that should be
> necessary to upgrade the system? I wouldn't interpret it this way.

That a "simple world upgrade" was meant is very clear from the full
meeting log, and from the log of the previous 2009-10-12 meeting (open
floor section).

Apparently the problem is neither new (see above, it existed in 2009)
nor is it uncommon. In fact, the Gentoo e.V. will have a workshop about
this topic on 2021-11-20 [1].

Ulrich

[1] https://gentoo-ev.org/news/online-workshops-2021/

[Aaron Bauman]

On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote:

> >>>>> On Wed, 03 Nov 2021, Rich Freeman wrote:
>
> > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann <whi...@gentoo.org> wrote:
> >>
> >> This is not about finding solution to upgrade the system (in this case
> >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
> >> about raising awareness that Gentoo is a rolling distribution and that
> >> we guarantee users to be able to upgrade their system when they do world
> >> upgrades just once a year (remember: in my case the last world upgrade
> >> is just 4 months old!). If they cannot upgrade their system without
> >> manual intervention, we failed to do our job.
>
> > Do we have this "guarantee" documented somewhere? I thought I've
> > heard six months tossed around. You say one year. It seems
> > reasonable to have some sort of guideline like this and try to stick
> > with it, at least for @system.
>
> We do. Summary of 2009-11-09 Council meeting:
>

I love digging through old council logs to find "policy"

Not sure why others don't feel the same way.

[Philip Webb]

211103 John Helmert III wrote:
> An "upgrade path" to me sounds like not just a world update,
> but also includes other stuff
> that might be necessary to get a system fully updated,
> like temporarily setting PYTHON_TARGETS to upgrade a package.
> A system without an upgrade path would seem to be a system
> where there is no way to upgrade it without reinstalling,
> which you seem to be asserting is the case for this system.

The Council resolution doesn't seem to have been well-thought-out :
why "1 year" & however could anyone measure that ?
what counts as an upgrade path ? -- problem-free or possible with some work ?

The basic problem is that Portage isn't capable of resolving all conflicts.
In order to do that, a great deal more programing work would be necessary,
which the hard-working volunteer developers are unlikely to have time for.
That means that users must put in a bit of their own time
& use some good sense based on experience to find a path for themselves.
People who can't do that shouldn't try using Gentoo.

I've been using Gentoo on all my machines for > 18 yr now
& have never tried to do 'emerge world' without '-pv',
and I've almost always been able to find my way thro' fairly quickly.
I have updated year-old systems occasionally with success.

You have to make a list of the pkgs which need updating
-- either by 'emerge -pv world' or via 'eix-sync' output -- ,
then work thro' the list updating a few pkgs at a time,
starting of course with the most fundamental, eg system pkgs.
That way, problems are usually easily identified
& often simply disappear when you put them aside & emerge further pkgs.
There are some regular blockages which require unmerging a set of pkgs
-- eg notoriously the Qt pkgs -- , then remerging all of them together.
Some problem pkgs can simply be left as they are & everything still works.

If you expect Portage to do all the work for you in the background,
it isn't going to succeeed.

HTH

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

[Andreas K. Huettel]

Am Mittwoch, 3. November 2021, 16:03:37 CET schrieb Thomas Deutschmann:
> Hi,
>
> it is currently not possible to smoothly run a world upgrade on a 4
> months old system which doesn't even have a complicated package list:
>

[snip]

Yup. We know. It's actually way worse than you describe [*] and was
noticed already quite some time ago. Unfortunately this is a situation
that can IMHO not be easily fixed, and we can only strive to do it
better next time.

The mistake was to allow the use of EAPI=8 too early. In the future, we
should have a new EAPI supported by portage for at least some months
before the EAPI is even used in the main tree. Not even speaking about
stable here.

From there on all the trouble cascades. And no, disallowing a new EAPI
for only a part of the tree does not help. (Which part?)

An alternative, which we should seriously consider (and which I've been
advocating for several months now) is to make Portage more robust, so
it can more easily upgrade itself, and keep the Portage ebuild at old
EAPI. This means,
* making Portage independent of the python eclasses, so it runs as long
as any python3 interpreter exists
* and bundling all Python dependencies it needs for functioning in it



[*] Of course there are ways around this to upgrade the system. However,
that is not the point. It should work out of the box.

--
Andreas K. Hüttel
dilf...@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[Rich Freeman]

On Wed, Nov 3, 2021 at 1:14 PM Ulrich Mueller <u...@gentoo.org> wrote:
>
> >>>>> On Wed, 03 Nov 2021, John Helmert wrote:
>
> >> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
> >> |
> >> | Upgrade path for old systems
> >> | ----------------------------
> >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> >> | stable system that hasn't been updated for one year.
>
> > Does "upgrade path" imply a simple world upgrade is all that should be
> > necessary to upgrade the system? I wouldn't interpret it this way.
>
> That a "simple world upgrade" was meant is very clear from the full
> meeting log, and from the log of the previous 2009-10-12 meeting (open
> floor section).
>

It probably would be good to get these policies documented someplace
OTHER than the council decision logs. I do remember the discussion
from the distant past but it is worth having it in a more prominent
place, especially since a one year stable update path is not going to
happen by accident.

I was thinking that it matters way more that @system is updatable than
world in general, since @system can be used to bootstrap everything
else. However, I think this distinction really doesn't make much of a
difference. If your system can't be smoothly updated, it is unlikely
to be due to some leaf package like a browser/MUA/etc. Most likely it
is due to a widely-used dependency.

So, by all means require @world to be updatable, but I think that if
you focus on the packages in @system you'll basically get the rest for
free.

EAPI 8 came up in a later email and to consolidate replies I'll just
say that the issue isn't so much adopting EAPIs in newer packages, but
the rush to tidy up old ones that creates the problems. If you have
v1/2/3 of a package stable and in the repo, and v3 uses an unsupported
EAPI, and v1 is installed, I think portage will (or at least ought to)
offer an upgrade from v1 to v2 - it should just not see v3 or consider
it in the depgraph. Of course keeping around old versions might
require dealing with security issues/etc that impact them. An
alternative would be of course to just avoid EAPI updates on @system
for a little while, or at least the parts of @system that portage
needs to upgrade.

Having QA tools detect this would be ideal, but right now they could
only reliably detect things like newer EAPIs in @system. Since we
don't require putting @system dependencies in packages there is no way
for a QA tool to tell what is or isn't needed to update portage. Then
you have more complex situations like PYTHON_TARGETS, and probably
others as well. I had one host that struggled a bit with the xcrypt
update for some reason (some weird preserved libs issue or something -
libcrypt was still showing up as owned by glibc after updating it and
I had to override collisions to get xcrypt to install). When
upgrading a system that is completely up to date requires careful
following of news items it is going to be painful to execute a whole
bunch of updates at once.

Maybe another path would be to mark milestone repositories for the
last year that are easy to update in sequence. So if you have an
update that requires manual care, you could mark a milestone just
before that update which is easy to get to, and then another one after
the update (ideally right before the next difficult update). This
would just be a snapshot of portage or a git commit reference, and
along with that a commitment to maintain distfiles/etc if they aren't
hosted in reliable places (ie patches/etc in devspace).

Another option might be to have collections of binary packages at key
milestones. Sure, they won't be built to a user's specification, but
if you have a year old system you could use them to quickly bootstrap
it up to something more recent, and then an emerge will rebuild
anything that has the wrong USE flags/etc and to bring the system
completely up to date. You could even just use those binary packages
as a sort of release-based version of the distro.

Just some things to consider.

--
Rich

[Ulrich Mueller]

>>>>> On Wed, 03 Nov 2021, Andreas K Huettel wrote:

> The mistake was to allow the use of EAPI=8 too early. In the future,
> we should have a new EAPI supported by portage for at least some
> months before the EAPI is even used in the main tree. Not even
> speaking about stable here.

I tend to disagree. Adding an ebuild with a new EAPI cannot break
anything, because it will simply be invisible to old package managers.

There won't be a problem unless you _remove_ ebuilds that are part of
the upgrade path.

Ulrich

[Ulrich Mueller]

>>>>> On Wed, 03 Nov 2021, Aaron Bauman wrote:

> I love digging through old council logs to find "policy"

> Not sure why others don't feel the same way.

Patches for the devmanual are welcome.

[Andreas K. Huettel]

Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller:
> >>>>> On Wed, 03 Nov 2021, Andreas K Huettel wrote:
>
> > The mistake was to allow the use of EAPI=8 too early. In the future,
> > we should have a new EAPI supported by portage for at least some
> > months before the EAPI is even used in the main tree. Not even
> > speaking about stable here.
>
> I tend to disagree. Adding an ebuild with a new EAPI cannot break
> anything, because it will simply be invisible to old package managers.

Except that you need to keep track of version dependencies across the whole
tree.

So, yes, this is in principle correct, and in practice with our current
tooling more or less impossible to do reliably.

[Part of the output Whissi pasted was (more or less) that a Perl upgrade
required a rebuild of Perl modules. Unfortunately, even a single one that
is not available for rebuild makes the emerge bail out.]

[Joshua Kinard]

On 11/3/2021 11:03, Thomas Deutschmann wrote:
> Hi,
>
> it is currently not possible to smoothly run a world upgrade on a 4
> months old system which doesn't even have a complicated package list:

[snip]

> This is not about finding solution to upgrade the system (in this case
> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
> about raising awareness that Gentoo is a rolling distribution and that
> we guarantee users to be able to upgrade their system when they do world
> upgrades just once a year (remember: in my case the last world upgrade
> is just 4 months old!). If they cannot upgrade their system without
> manual intervention, we failed to do our job.
>
> Situations like this will disqualify Gentoo for any professional
> environment like this will break automatic upgrades and you cannot roll
> individual fixes for each possible situation via CFM tools like Salt,
> Ansible, Puppet or Chef.
>
> It would be very appreciated if everyone will pay more attention to this
> in future. We can do better. In most cases we can avoid problems like
> this by keeping older ebuilds around much longer for certain key
> packages to help with upgrades.
>
> Thank you.

Actually, it is possible to manage dependency errors like those. It just
takes a *lot* of elbow grease, and and long, long time time. Especially if
you have museum-grade hardware that these errors are happening on.

For Perl, I've usually just uninstall everything under virtual/* first, then
try to let it upgrade. Sometimes that "unsticks" something in perl-core
enough to let the upgrades apply, pulling back in any needed items from
virtual/. If that doesn't solve the problem enough to let emerge do an
upgrade cycle, I'll try using just the @system target, or start yanking
things out from perl-core/* one-by-one until emerge shuts up and does what
it is told.

Also, *always* check for libperl-www being in the package list. It's
usually sucked in by way of dev-util/intltool and is responsible for ~35-40
perl packages alone being pulled in. If that's in the list, try
uninstalling just that one, then run a depclean to remove all of its
dependencies and then see if the upgrade will work. If the upgrade tries to
drag intltool or libperl-www back in, use --exclude to hold it out for later.

That all said, am I alone in thinking that the way Portage emits error
messages about dependency resolution problems is extremely messy and
border-line unreadable at times? The current way it outputs depgraph errors
feels like something I'd expect from a --debug switch. We've got a
reputation for being playful and colorful on the command line with our
tooling, so I would wonder if that depgraph output couldn't be made to
look....nicer?

--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

[Philip Webb]

211103 Joshua Kinard wrote:
> That all said, am I alone in thinking

> the way Portage emits error messages about dependency resolution problems
> is extremely messy and border-line unreadable at times?
> The current way it outputs depgraph errors
> feels like something I'd expect from a --debug switch.
> We've got a reputation for being playful and colorful on the command line
> with our tooling, so I would wonder if that depgraph output
> couldn't be made to look....nicer?

As a longtime user, I can say you aren't alone (smile).
Portage error msgs are difficult to read & often simply unhelpful.

[Alec Warner]

On Wed, Nov 3, 2021 at 2:50 PM Andreas K. Huettel <dilf...@gentoo.org> wrote:
>
> Am Mittwoch, 3. November 2021, 22:39:41 CET schrieb Ulrich Mueller:
> > >>>>> On Wed, 03 Nov 2021, Andreas K Huettel wrote:
> >
> > > The mistake was to allow the use of EAPI=8 too early. In the future,
> > > we should have a new EAPI supported by portage for at least some
> > > months before the EAPI is even used in the main tree. Not even
> > > speaking about stable here.
> >
> > I tend to disagree. Adding an ebuild with a new EAPI cannot break
> > anything, because it will simply be invisible to old package managers.
>
> Except that you need to keep track of version dependencies across the whole
> tree.
>
> So, yes, this is in principle correct, and in practice with our current
> tooling more or less impossible to do reliably.

I think the obvious easy solution here is to run a CI that is using
older stuff, and report problems when commits break that.

It's less clear what to do about it though; the problems Whissi
raised.. it's not like we didn't know about them (they were known),
but we chose not to do anything about it?
Or we learned about them too late (and figured the majority of users
had seen it; so fixing them was not necessary?)

-A

[Sam James]

> On 3 Nov 2021, at 15:03, Thomas Deutschmann <whi...@gentoo.org> wrote:
>
> Hi,
>
> it is currently not possible to smoothly run a world upgrade on a 4 months old system which doesn't even have a complicated package list:

> [snip]

>
> This is not about finding solution to upgrade the system (in this case it was enough to force PYTHON_TARGETS=python3_8 for portage). This is about raising awareness that Gentoo is a rolling distribution and that we guarantee users to be able to upgrade their system when they do world upgrades just once a year (remember: in my case the last world upgrade is just 4 months old!). If they cannot upgrade their system without manual intervention, we failed to do our job.
>
> Situations like this will disqualify Gentoo for any professional environment like this will break automatic upgrades and you cannot roll individual fixes for each possible situation via CFM tools like Salt, Ansible, Puppet or Chef.
>
> It would be very appreciated if everyone will pay more attention to this in future. We can do better. In most cases we can avoid problems like this by keeping older ebuilds around much longer for certain key packages to help with upgrades.

I agree wholeheartedly with this and thank you for raising it.

## Remark on some previous discussion

First, let me just mention that I think it's been on some of our minds but we need to go a bit further with formalising matters. It was brought up at the end of the September 2021 council meeting as a footnote:
```
[21:16:56] <@sam_> I'd like to consider "upgrade lifcycles" at some point but I don't have notes ready for now. Mainly just about formalising efforts to support upgrades for X period and to try document a procedure for e.g. new EAPI versions and bootstrap packages not having new EAPIs for a while, and such.
[21:17:09] <@sam_> So, no, not right now, but I'd welcome any thoughts post-meeting while I consider it more
[21:17:33] <@sam_> The gist is to have a checklist so that we don't "get excited" like with EAPI 8 and end up making upgrades hard for people
[21:17:43] <@sam_> I think the GLEP we recently approved helps with that
```

I started working on some notes too on possible improvements: https://wiki.gentoo.org/wiki/User:Sam/TODO#Improving_upgrades. (I wanted to mention all of this here because
it's easy to lose track of e.g. council meeting references on a topic, so it's easy to find it in the thread now.)

## Summary of the two common cases

Now, in terms of the common issues regarding upgrades, I think we have two (to be clear, not trying to "fix your problem" -- just bring to bear some of the
support experience I've had from #gentoo and so on):

1) World upgrades which can't complete due to new EAPIs (one's Portage lacks support for e.g. EAPI 8 and hence cannot read ebuilds)

I'm open to more broad measures about usage of new EAPIs in ~arch / stable (say, e.g. the first Portage supporting EAPI N should sit in
~arch for 4/6/??? months before any ebuilds should use it?), but I think this is a drastic measure we might be able to avoid. Let's keep it
in mind in case we do need it though.

My general thinking on this is that it doesn't matter _too much_(?) as long as one can upgrade Portage without hassle. A lot of our
users seem to know to try upgrade Portage if they can't upgrade their system due to new EAPIs, but they then fall down due to
cryptic errors (see my next point). We could also improve the "unknown EAPI" error if necessary to make this more clear.

TL;DR: We might be able to leverage a more drastic option, but my hope is we can avoid any direct action in handling 1) if we deal
with the next point I'm about to make (2)).

2) Portage often can't upgrade itself when there's "pending global PYTHON_TARGETS changes" (e.g. when we change the default value of
PYTHON_TARGETS in the profiles (like from Python 3.8 to Python 3.9))

This one is far trickier. I've started documenting common hacks/methods at https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Upgrading_Portage#Solution
which has been rather useful in #gentoo and on the forums (it's been nice to see links on those and other similar pages pop up on /r/gentoo).

Portage is written in Python and has dependencies in Python. A lot of them are optional (which is why in the wiki page
I linked to, I suggest emerge --syncing and then turning off USE=rsync-verify temporarily to reduce dependencies), but
I don't think this is particularly comforting to a user who just wants to upgrade Portage. They don't necessarily realise
they need to toggle one or *several* flags on Portage to make it work.

dilfridge has been advocating for some time that we try look at some form of a "static Portage" copy (possibly
vendoring/bundling all Python dependencies) to completely decouple the Portage ebuilds from the Python
eclasses other than needing a (modern) Python 3 interpreter.

[I've filed a bug for this here: https://bugs.gentoo.org/821511].

I really feel like this is one of the big things we need to tackle. Upgrading Portage unlocks newer
EAPIs and allows us to even discuss world upgrades.

(Using an older Portage to try upgrade world with any non-trivial @world set (chosen, user-specified packages)
is likely to be a fool's errand -- folks have already said that if _anything_ is using a new EAPI, it's going to affect
some users and result in confusing errors.)

## Solutions

* News item when a new EAPI is released explaining how to upgrade Portage in case of emergency / inability
to upgrade Portage.

We can describe the steps at https://wiki.gentoo.org/wiki/Project:Portage/Fixing_broken_portage:

This would also flag to users that they should upgrade Portage sooner-rather-than-later even if they aren't
currently willing/able to fully upgrade the rest of their system.

* We may want to include a 'rescue-portage' script on the system which downloads the latest Portage (would need
to use a symlink or something to reliably get the latest version).

* Investigate reducing Portage's dependencies.

* Mitigate PYTHON_TARGETS profile change impact:
** I don't love this idea but one possible measure is that we always have two PYTHON_TARGETS set
at all times (this would double build times for a fair amount of packages).
** Or we do this just for Portage and its dependencies.
** Or we have a new portage-minimal ebuild (to simplify matters) which always has some/all targets enabled,
which will have few/no Python dependencies.

[Note that in the past, we weren't consistent about putting out news items for this change. We're doing
that now at least.

The matter has got a bit worse because of Python upstream's release cycle changing.]

* Implement at least a 4-6 month(?) delay on using new EAPIs after a new version of Portage
supports it (the timer resetting once it hits stable too).

I wasn't sure about this at first, but actually, the PYTHON_TARGETS stuff _should_ be
fine for the most part as long as we make sure the tree is mostly/entirely ready before
flipping the switch.

[This could actually help with a fair amount of the problems (other than "general upgrade
issues" like conflicts) except when a new EAPI comes along with a targets change,
and if we're looking to support upgrades over a year or two years, that's.. probably
going to coincide.]

## TL;DR

I don't think we can avoid thinking about Portage's entanglement / relationship
with PYTHON_TARGETS. Banning use of new EAPIs immediately will not magically
make it easy to upgrade Portage itself.

But the combination of a new EAPI + PYTHON_TARGETS changes in profiles
is pretty lethal.

I've got a few ideas above and I hope we can discuss some of them, or even better,
someone has other proposals.

best,
sam

[Sam James]

> On 3 Nov 2021, at 20:16, Rich Freeman <ri...@gentoo.org> wrote:
> It probably would be good to get these policies documented someplace
> OTHER than the council decision logs. I do remember the discussion
> from the distant past but it is worth having it in a more prominent
> place, especially since a one year stable update path is not going to
> happen by accident.

+1

> I was thinking that it matters way more that @system is updatable than
> world in general, since @system can be used to bootstrap everything
> else. However, I think this distinction really doesn't make much of a
> difference. If your system can't be smoothly updated, it is unlikely
> to be due to some leaf package like a browser/MUA/etc. Most likely it
> is due to a widely-used dependency.
> So, by all means require @world to be updatable, but I think that if
> you focus on the packages in @system you'll basically get the rest for
> free.

This isn't quite true because it's very possible that plenty of things
will have e.g. subslot deps on @system packages and therefore
are holding them back if a change happens (you want to rebuild
everything together).

> EAPI 8 came up in a later email and to consolidate replies I'll just
> say that the issue isn't so much adopting EAPIs in newer packages, but
> the rush to tidy up old ones that creates the problems.

Right. I think we could really try to just not cleanup so aggressively
unless we know there's some nasty < dep in the ebuild.

There's another really good reason for this: stabilisation and such
doesn't catch everything, and you might find you just got upgraded
to a newly-stabled ebuild which doesn't work, and now you have
to fight to downgrade because cleanup was immediately done!

> Having QA tools detect this would be ideal, but right now they could
> only reliably detect things like newer EAPIs in @system. Since we
> don't require putting @system dependencies in packages there is no way
> for a QA tool to tell what is or isn't needed to update portage. Then
> you have more complex situations like PYTHON_TARGETS, and probably
> others as well. I had one host that struggled a bit with the xcrypt
> update for some reason (some weird preserved libs issue or something -
> libcrypt was still showing up as owned by glibc after updating it and
> I had to override collisions to get xcrypt to install). When
> upgrading a system that is completely up to date requires careful
> following of news items it is going to be painful to execute a whole
> bunch of updates at once.

(We did work very hard on this to make it as smooth as possible
and we've also dropped the workaround which caused the intentional
collision (which we mentioned in the news item + glibc's pkg_postinst)
which Portage should've ignored with default FEATURES b/c the file
was orphaned, but it should be better now.)

best,
sam

[Sam James]

> On 3 Nov 2021, at 22:15, Joshua Kinard <ku...@gentoo.org> wrote:
> Actually, it is possible to manage dependency errors like those. It just
> takes a *lot* of elbow grease, and and long, long time time. Especially if
> you have museum-grade hardware that these errors are happening on.
>
> For Perl, I've usually just uninstall everything under virtual/* first, then
> try to let it upgrade. Sometimes that "unsticks" something in perl-core
> enough to let the upgrades apply, pulling back in any needed items from
> virtual/. If that doesn't solve the problem enough to let emerge do an
> upgrade cycle, I'll try using just the @system target, or start yanking
> things out from perl-core/* one-by-one until emerge shuts up and does what
> it is told.

For what it's worth, you really really shouldn't need to do this.

Perl is great at consuming backtracking cycles (largely because
of all of the || ( ... .... ) deps in the virtuals) and cranking that
up helps a lot.

But something which we're not really clear enough on is that
users should genuinely never have to use emerge -C / --unmerge.

Trying just @system shouldn't be needed either and is in fact
likely to be more problematic:

https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_when_I_attempt_to_upgrade_a_single_package.3F

> Also, *always* check for libperl-www being in the package list. It's
> usually sucked in by way of dev-util/intltool and is responsible for ~35-40
> perl packages alone being pulled in. If that's in the list, try
> uninstalling just that one, then run a depclean to remove all of its
> dependencies and then see if the upgrade will work. If the upgrade tries to
> drag intltool or libperl-www back in, use --exclude to hold it out for later.
>

Aye, we fixed eudev to not need it anymore and there's an avahi
bug for the same I'll look at shortly.

> That all said, am I alone in thinking that the way Portage emits error
> messages about dependency resolution problems is extremely messy and
> border-line unreadable at times? The current way it outputs depgraph errors
> feels like something I'd expect from a --debug switch. We've got a
> reputation for being playful and colorful on the command line with our
> tooling, so I would wonder if that depgraph output couldn't be made to
> look....nicer?
>

Yeah, I think one of our biggest weaknesses is that there's
usually a LOT of output and figuring out what matters isn't easy.

A good rule of thumb is that the "most fatal" error is _usually_
at the bottom but this isn't always true.

Best,
sam

[Andreas K. Huettel]

> I think the obvious easy solution here is to run a CI that is using
> older stuff, and report problems when commits break that.

Something that's been bouncing around my head:

* archive stage3 files somewhere official

* run a weekly CI job that attempts to upgrade a N-weeks old
stage3 to current, with "emerge -uDNav world"

* for N=1,2,4,8,16,32 etc

* if it fails, annoy people

Limitations:
1) covers only stage3
2) solutions may not always be obvious
3) culprits may not always be obvious

[Aaron Bauman]

Is that where the policy belongs?

If so, shouldn't the council update it based on their decisions?

"patches are welcome" doesn't fit every scenario.

-Aaron

[Sam James]

> On 3 Nov 2021, at 23:53, Aaron Bauman <bm...@gentoo.org> wrote:
> Is that where the policy belongs?
> If so, shouldn't the council update it based on their decisions?
> "patches are welcome" doesn't fit every scenario.

Got to agree here. If there's a gap in the documentation,
let's file a bug -- irrespective of if someone is going to give
a patch.

Just commenting this on the ML means it'll get lost
and we'll forget about it...

Best,
sam

[Sam James]

Filed https://bugs.gentoo.org/821553. Please
feel free to clarify it.

[John Helmert III]

Thank you! Many of us apparently have differing interpretations of the
policy (and it's somewhat hidden), so a clear policy in an obvious
place will be a huge improvement!

[Rolf Eike Beer]

Philip Webb wrote:

> Portage error msgs are difficult to read & often simply unhelpful.

With difficult to read you mean something like "someone decided that it's a
good idea to print the blocked packages atoms in dark blue on black and other
stuff in yellow so it would be equally unreadable on white background", right?

Just going to hide again,

Eike

[Philip Webb]

If you're serious, I mean that they're difficult to parse.

> Just going to hide again,

If you meant to be humorous, that's the best place for your blushes (smile).

[Kai Krakow]

For me, Qt packages are often a blocker... It seems that on
slot-change, portage isn't able to consider all reverse dependencies
for rebuilt - or rather: It doesn't consider that the old slots
will/can be uninstalled later. I think something similar happens for
perl. Usually, I can solve this by adding `--reinstall-atoms="$(qlist
-IC dev-qt/ dev-perl/)" to the cmdline, then add the remaining reverse
dependencies that need to be rebuilt, too, but portage doesn't
consider for some reason. Usually, that catches more packages than
actually really need to be rebuilt but it cuts down the messy
dependency graph in the error message a lot and enables me to finally
handle it in a sane way. Python upgrades, tho, are a lot weirder and
harder to resolve because it involves portage itself. The latest EAPI
bump was a hard one when I didn't update portage for some time (yes,
it's recommended to do that but that's not always possible for
production containers, and there's also not always time to do that,
and least we are working with containers now with cut down
dependencies, staging and cloning updates with
single-purpose/single-service containers is a lot less headache).

I'm not sure what the problem is here: Somehow portage isn't able to
reach the final result. But then, maybe it should consider not
upgrading all packages at once and even consider less recent package
versions for dependency resolving. This probably would explode the
whole resolver algorithm - and that needs to be optimized properly.
But I'd rather prefer to run portage twice or even more often, if it
at least resolves to an intermediate solution with not always the
latest package versions.

But I'm pretty sure one central problem is portage not always
considering packages for rebuilds properly - and that seems to mostly
happen on slot changes when there are mixed reverse dependencies: some
that depend on a slot, and some that don't. Maybe some resolve
candidates are eliminated just too early from the dependency graph...

That said, I'm usually able to avoid uninstalling packages by using
`--reinstall-atoms`, and sometimes it just needs an `emerge
--deselect` because something stuck it into the world file for reasons
I cannot understand (I'm really picky about what goes into my world
file and try to keep it at the minimum needed).

> That all said, am I alone in thinking that the way Portage emits error
> messages about dependency resolution problems is extremely messy and
> border-line unreadable at times? The current way it outputs depgraph errors
> feels like something I'd expect from a --debug switch. We've got a
> reputation for being playful and colorful on the command line with our
> tooling, so I would wonder if that depgraph output couldn't be made to
> look....nicer?

Yep, it's hard to read. It takes a steep learning curve to properly
read those messages and understand what they are telling you, and then
an even steeper learning curve to figure out what action actually has
to be taken. And it doesn't help when portage omits packages with "and
27 other packages with a similar problem" when exactly those are the
ones I'd need to manually stick to the reinstall list. And something
in my head says: "Why doesn't portage just consider those for
automatic reinstall?" - well, probably it did, I'm pretty sure it did.
But something eliminated those too early from the resolve. Increasing
the backtracking usually does exactly nothing except the resolve runs
**a lot** longer.

Regards,
Kai

[Pacho Ramos]

I haven't tried yet as, fortunately, I have been able to deal with the conflicts
most of the times but, I was wondering if one workaround would be to simply try
to use emerge-webrsync --revert= option.

That way, people could try to upgrade their old systems going from the oldest
tree to, for example, the tree from August of this year. Later they could update
to a newer snapshot and follow until the end