| Summary: | any-of-many dependency in python-any-r1 pulls in dev-lang/python-3.9.0 even though the dependency is already satisfied | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Ellison Marks <gotyaoi> |
| Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ellison Marks
2020-11-07 10:31:10 UTC
(In reply to Ellison Marks from comment #0) > Expected Results: > the dependency is satisfied by the existing python 3.7.9 or 3.8.5 and python > 3.9.0 remains unmerged The problem is, if it behaved that way it would prevent you from getting latest available versions of packages. If you don't want the latest version, then you'll have to add it to package.mask, like this: echo '>=dev-lang/python-3.9' >> /etc/portage/package.mask How would it prevent me from getting the latest available version? Presumably something would eventually change on my system, either use flag related or adding it to my world file, that would pull in 3.9. Until that happens all my dependencies should already be satisfied. Masking it would in fact prevent me from getting the latest version, even if it was required. When that use or world change eventually happens, I'd probably have emerge problems until I remembered to go unmask it. *** This bug has been marked as a duplicate of bug 702806 *** (In reply to Ellison Marks from comment #2) > How would it prevent me from getting the latest available version? > Presumably something would eventually change on my system, either use flag > related or adding it to my world file, that would pull in 3.9. For emerge -uD @world, the general expectation is that all packages will be updated to latest available version. This expectation is unrelated to USE flag settings. It's related to your world file in the sense that having dev-lang/python:3.9 in your world file would trigger similar behavior to the python-any-r1 dependencies. I'm not sure that's the case here though? If dev-lang/python:3.9 were pulled into the dependency graph, then of course portage should keep the latest python 3.9 installed. In this case however, what gets pulled into the dependency graph by glibc's python-any-r1 is || ( dev-lang/python:3.9 dev-lang/python:3.8 dev-lang/python:3.7 dev-lang/python:3.6 ) If I didn't have any python installed, then dev-lang/python:3.9 would be chosen and the latest python 3.9 installed, but since dev-lang/python-3.8.5 is already installed, the dependency should be satisfied from it's dev-lang/python:3.8 member and portage should simply ensure that the latest python 3.8 is installed. Basically, it seems like as long as any slot from python-any-r1's PYTHON_COMPAT is installed, it shouldn't try to install another slot. The only time python-any-r1 should be responsible for installing python is if none of the slots in PYTHON_COMPAT are installed. The only reason that I mentioned use flags is that, say, eventually python_targets_python3_9 will enter the default python_targets set, causing the latest python 3.9 to get installed, and then glibc's python-any-r1 dependency would be satisfied by it's dev-lang/python:3.9 member. (In reply to Ellison Marks from comment #5) > Basically, it seems like as long as any slot from python-any-r1's > PYTHON_COMPAT is installed, it shouldn't try to install another slot. The > only time python-any-r1 should be responsible for installing python is if > none of the slots in PYTHON_COMPAT are installed. That would lead to problems like bug 706278 (missed llvm slot upgrade). That bug is a slightly different situation from this case. The reporter states that "mesa is the only package which requires llvm in my system." So it's probably appropriate for llvm to be upgraded to the latest slot that mesa will allow. In this case however, other packages are already pulling in slots of python that are acceptable to glibc's python-any-r1, so pulling in the python 3.9 seems superfluous. pulling it in doesn't break any dependencies, but it's also not necessary to satisfy any dependencies. However, I can also understand the position that as long as it doesn't break any dependencies, it is preferable to use the latest version allowed. It seems like this may be a split between wanting to have the latest version and wanting to have the fewest number of packages installed to satisfy the given dependencies. (In reply to Ellison Marks from comment #7) > However, I can also understand the position that as long as it doesn't break > any dependencies, it is preferable to use the latest version allowed. It > seems like this may be a split between wanting to have the latest version > and wanting to have the fewest number of packages installed to satisfy the > given dependencies. Right, and missed updates tend to be extremely undesirable since that can mean missed bug fixes. The package.mask file allows fine-grained control so that you can miss specific updates on purpose if you want. You'll naturally be notified when those updates become necessary since it will trigger some kind of dependency resolution failure which will refer to your corresponding package.mask entry. It's best to include a comment above the package.mask entry so that emerge can output the comment when the failure occurs. |
