Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 722748 - sys-apps/portage: suggestion to 'emerge --oneshot sys-apps/portage' causes confusion after global PYTHON_TARGETS updates
Summary: sys-apps/portage: suggestion to 'emerge --oneshot sys-apps/portage' causes co...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All All
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
: 758581 761349 (view as bug list)
Depends on:
Blocks: 778869
  Show dependency tree
 
Reported: 2020-05-12 18:29 UTC by Zac Medico
Modified: 2021-08-11 19:35 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zac Medico gentoo-dev 2020-05-12 18:29:39 UTC
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.
Comment 1 Zac Medico gentoo-dev 2020-05-12 19:06:01 UTC
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.
Comment 2 Zac Medico gentoo-dev 2020-05-12 19:18:06 UTC
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.
Comment 3 Mike Gilbert gentoo-dev 2020-05-12 19:18:20 UTC
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.
Comment 4 Zac Medico gentoo-dev 2020-05-12 20:46:52 UTC
(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.
Comment 5 Michael 'veremitz' Everitt 2020-05-16 00:42:24 UTC
(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...
Comment 6 Ionen Wolkens gentoo-dev 2020-10-02 18:28:24 UTC
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
Comment 7 Zac Medico gentoo-dev 2020-10-02 19:24:52 UTC
<[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.)
Comment 8 Zac Medico gentoo-dev 2020-10-02 19:28:44 UTC
(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.
Comment 9 Ionen Wolkens gentoo-dev 2020-10-02 22:36:29 UTC
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.
Comment 10 Ionen Wolkens gentoo-dev 2020-10-02 22:49:45 UTC
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.
Comment 11 Zac Medico gentoo-dev 2020-10-02 23:35:52 UTC
(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.
Comment 12 Ionen Wolkens gentoo-dev 2020-10-03 00:13:45 UTC
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.
Comment 13 Zac Medico gentoo-dev 2020-12-06 00:05:23 UTC
*** Bug 758581 has been marked as a duplicate of this bug. ***
Comment 14 Anatoly Laskaris 2020-12-06 08:07:26 UTC
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.
Comment 15 Larry the Git Cow gentoo-dev 2020-12-06 08:27:15 UTC
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(-)
Comment 16 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-12-23 16:45:57 UTC
*** Bug 761349 has been marked as a duplicate of this bug. ***
Comment 17 Zac Medico gentoo-dev 2021-03-28 07:21:38 UTC
(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.
Comment 18 Larry the Git Cow gentoo-dev 2021-03-29 06:43:26 UTC
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(-)
Comment 19 Larry the Git Cow gentoo-dev 2021-03-29 07:34:11 UTC
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(+)
Comment 20 Michael 'veremitz' Everitt 2021-04-26 03:25:05 UTC
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?