We just had a global python3_6 -> python3_7 PYTHON_TARGETS change, which causes 'emerge --oneshot sys-apps/portage' to fail miserably, causing confusion for users.
It's rarely necessary to update portage in advance, so I think it's probably fine to remove this notification. The notification is mainly useful for people who don't do full world updates regularly. If they let portage get too far out of date then they'll eventually have problems, but maybe it's better to let those people learn the hard way.
We can turn it into a FEATURES setting (or --sync-portage-upate-nag option that can be enabled via EMERGE_DEFAULT_OPTS), so people can enable it if it's useful to them.
I recall there was an issue where some packages would record the path to the "install" binary based on the temporary copy of portage, and then use this path later at runtime. I don't have a bug number handy.
(In reply to Mike Gilbert from comment #3) > I recall there was an issue where some packages would record the path to the > "install" binary based on the temporary copy of portage, and then use this > path later at runtime. I don't have a bug number handy. I'd say those packages should have a configure option to override the location that's being hardcoded there.
(In reply to Mike Gilbert from comment #3) > I recall there was an issue where some packages would record the path to the > "install" binary based on the temporary copy of portage, and then use this > path later at runtime. I don't have a bug number handy. Yup, Arfever has it right as bug #461824 . I see this periodically with catalyst builds, and if you exit/re-enter the chroot, you can 'lose' this temporary copy of portage's helpers when it cleans up, but the temporary path is cached, such that you have to symlink the correct location to complete an incomplete build...
Considering the switch to python3.8 is slowly approaching (2020-12-01 "if" as planned[0]), it may be useful to visit this bug soon. I imagine people will be trying to update portage on its own again, and if a new portage happens to be stabilized around same time (again) we'll likely get a lot of failure reports. Was reminded of this because people still report problems trying to --oneshot portage as "_highly_ recommended" while updating old pre-3.7 systems right now. [0] https://wiki.gentoo.org/wiki/Project:Python/Implementations
<[Arfrever]> Maybe emerge could suggest: <[Arfrever]> 1. emerge -1 dev-lang/python:${new_slot} <[Arfrever]> 2. emerge -1O sys-apps/portage <[Arfrever]> (Only if PYTHON_TARGETS for sys-apps/portage changed.)
(In reply to Zac Medico from comment #7) > <[Arfrever]> Maybe emerge could suggest: > <[Arfrever]> 1. emerge -1 dev-lang/python:${new_slot} > <[Arfrever]> 2. emerge -1O sys-apps/portage > <[Arfrever]> (Only if PYTHON_TARGETS for sys-apps/portage changed.) I think this is still likely to trigger conflicts if a python target was dropped.
Some possible options I can think of: - PYTHON_TARGETS="targets that current portage is built with" emerge -1 portage - add a "update-portage" script and tell users to run that instead, could do as many checks as necessary without confusing users - in-emerge hook to update itself properly and then restart itself that could be disabled with an option if need be, but I imagine that could get messy - don't make suggestion _highly_ recommended and only "in case of problems" - remove suggestion entirely, if portage _need_ to be updated the system is likely so old that users might as well head to the update old system wiki page.
Or I guess could only hide the suggestion when it's known that it's going to fail (e.g. dropped target). Users will likely move on, read the news item, and update their system without realizing portage is pending.
(In reply to Ionen Wolkens from comment #9) > Some possible options I can think of: > > - PYTHON_TARGETS="targets that current portage is built with" emerge -1 > portage Too complicated. > - add a "update-portage" script and tell users to run that instead, could do > as many checks as necessary without confusing users Too complicated. > - in-emerge hook to update itself properly and then restart itself that > could be disabled with an option if need be, but I imagine that could get > messy Too complicated. > - don't make suggestion _highly_ recommended and only "in case of problems" Very reasonable, but "in case of problems" is not the only time when it's a good idea to update portage. > - remove suggestion entirely, if portage _need_ to be updated the system is > likely so old that users might as well head to the update old system wiki > page. The thing is, people may induce such a state simply because they're unaware that it's a good idea to update portage at the earliest opportunity. They might selectively update whatever apps they happen to care about, while allowing portage to grow more and more out of date. (In reply to Ionen Wolkens from comment #10) > Or I guess could only hide the suggestion when it's known that it's going to > fail (e.g. dropped target). Users will likely move on, read the news item, > and update their system without realizing portage is pending. I think that trying to predict when the dependency calculation will fail might be a bit too complicated. So, maybe we should suggest to fall back to a deep world update if the 'emerge --oneshot sys-apps/portage' dependency calculation fails.
Yeah being too complicated is a good point. I guess one more option could be to do nothing here, but for the news item to address how to handle portage during python migration. Although adding more text to read to news items is its own problem.
*** Bug 758581 has been marked as a duplicate of this bug. ***
Regarding the recent change to PYTHON_TARGETS="python2_7 python3_8" https://github.com/gentoo/gentoo/commit/a9845b9cd3f74ee6a7ef7de70a282ec246c492f1 I beilive BOOTSTRAP_USE should also be updated. >This MUST be kept in sync with the PYTHON_TARGETS below https://github.com/gentoo/gentoo/blob/master/profiles/base/make.defaults#L123 I was trying to emerge gentoolkit on a recent autobuilt stage3 and got slot conflicts. Not sure there is a need to file another bug report.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2cbbf8a6271301b928d5c1d5dce435c2a291c8ae commit 2cbbf8a6271301b928d5c1d5dce435c2a291c8ae Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2020-12-06 08:13:24 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2020-12-06 08:27:11 +0000 profiles/base: sync BOOTSTRAP_USE with PYTHON_TARGETS Fixes: a9845b9cd3f7 ("profiles/base: swith to python3.8 by default") Reported-by: Anatoly Laskaris <nahsimail@airmail.cc> Bug: https://bugs.gentoo.org/722748#c14 Signed-off-by: Zac Medico <zmedico@gentoo.org> profiles/base/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
*** Bug 761349 has been marked as a duplicate of this bug. ***
(In reply to Zac Medico from comment #0) > We just had a global python3_6 -> python3_7 PYTHON_TARGETS change, which > causes 'emerge --oneshot sys-apps/portage' to fail miserably, causing > confusion for users. I'd like to suppress the message when there are PYTHON_TARGETS changes, since it is easy to detect, and should be the most common failure scenario.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=ba9866db877afdfe20d11768007233da6334d578 commit ba9866db877afdfe20d11768007233da6334d578 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-03-29 05:55:53 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-03-29 06:42:28 +0000 SyncRepos: suppress portage update message if PYTHON_TARGETS changed When PYTHON_TARGETS changed, the emerge --oneshot portage suggestion a nuisance, therefore suppress it. Bug: https://bugs.gentoo.org/722748 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/emaint/modules/sync/sync.py | 40 +++++++++++++++++++++++++++---- lib/portage/tests/sync/test_sync_local.py | 15 +++++++++--- 2 files changed, 48 insertions(+), 7 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b227821cc18ee50ede6b9cb6493820a0460cd1bb commit b227821cc18ee50ede6b9cb6493820a0460cd1bb Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2021-03-29 07:31:19 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2021-03-29 07:34:04 +0000 sys-apps/portage: Bump to version 3.0.18 #651208 profile-repo-deps profile-formats support #719260 remove glsa --quiet blank line #722748 suppress emerge --oneshot portage suggestion Bug: https://bugs.gentoo.org/778869 Bug: https://bugs.gentoo.org/651208 Bug: https://bugs.gentoo.org/719260 Bug: https://bugs.gentoo.org/722748 Package-Manager: Portage-3.0.18, Repoman-3.0.2 Signed-off-by: Zac Medico <zmedico@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.18.ebuild | 279 +++++++++++++++++++++++++++++++++ 2 files changed, 280 insertions(+)
For some scenarios where updating package X may go Horribly Wrong™ there is a useful 'howto unbrick X' article on the Wiki which is referenced in relevant ebuilds. Is this something which might get us out of the 'stick' of making portage self-fix in this scenario, which as Zac points out, could easily break or need constant updating to keep in-sync?
