| View previous topic :: View next topic |
| Author |
Message |
jeffss
n00b
Joined: 13 Sep 2019
Posts: 53
|
 Posted: Tue Aug 15, 2023 2:02 pm Post subject: about adding priority groups to the world set |
 |
|
| That is something I have been considering for some time, as it adds some more complexity for writing the dependency resolutions, however it may also significatively reduce complexity on the overall execution of merge operations, like world upgrades. The idea is that often anyway it is required to accept that some packages will break as a result of the resolutions, either it is too complicated to find a solution or there is not really some solution, so a way to add some organization could be to define that some packages are more acceptable to break then others, possibly also including a flag to turn on or off the consideration of that priority |
|
| Back to top |
|
 |
pingtoo
l33t
Joined: 10 Sep 2021
Posts: 955
Location: Richmond Hill, Canada
|
| Posted: Tue Aug 15, 2023 2:44 pm Post subject: |
|
|
| I don't know how feasible to implementation, but totally agree and support this concept. |
|
| Back to top |
|
|
Kangie
n00b
Joined: 21 May 2023
Posts: 2
Location: Brisbane, Australia
|
| Posted: Fri Aug 18, 2023 3:03 am Post subject: Re: about adding priority groups to the world set |
|
|
| jeffss wrote: | | it is required to accept that some packages will break as a result of the resolutions |
Is it? None of my systems break like that.
| jeffss wrote: | | either it is too complicated to find a solution or there is not really some solution, so a way to add some organization could be to define that some packages are more acceptable to break then others, possibly also including a flag to turn on or off the consideration of that priority |
I fail to see what this adds over `--exclude` and/or `--keep-going` aside from a _ton_ of additional complexity in portage to handle an edge case that probably comes from misunderstanding how dependencies in portage actually work (i.e. how likely this is to break something that isn't the package you're "intending" to break).
Could you elaborate on why you think this is a good idea? |
|
| Back to top |
|
|
jeffss
n00b
Joined: 13 Sep 2019
Posts: 53
|
| Posted: Thu Sep 21, 2023 2:34 pm Post subject: Re: about adding priority groups to the world set |
|
|
| Kangie wrote: | | jeffss wrote: | | it is required to accept that some packages will break as a result of the resolutions |
Is it? None of my systems break like that.
| jeffss wrote: | | either it is too complicated to find a solution or there is not really some solution, so a way to add some organization could be to define that some packages are more acceptable to break then others, possibly also including a flag to turn on or off the consideration of that priority |
I fail to see what this adds over `--exclude` and/or `--keep-going` aside from a _ton_ of additional complexity in portage to handle an edge case that probably comes from misunderstanding how dependencies in portage actually work (i.e. how likely this is to break something that isn't the package you're "intending" to break).
Could you elaborate on why you think this is a good idea? |
I don't know if that is because of something I am doing wrong, but for instance regularly after upgrades of the qt/kde ecossystem, with changes of soname dependencies, some interfaces break for a while, until some packages are rebuilt, and conflicts are also usually common. About the exclude, a reason I see for automation is that often it is possible to know what operations to do in order to single out a list of packages, but executing manually takes time. The main reason I considered for this feature is that often taking too much time for completing updates can be problematic then some temporary issue that could last at most a couple of hours or a day. But anyway I am not sure about the details of implementation, so you may very well be correct about the priority of implementing it |
|
| Back to top |
|
|
jeffss
n00b
Joined: 13 Sep 2019
Posts: 53
|
| Posted: Thu Sep 21, 2023 2:43 pm Post subject: |
|
|
| maybe also some possibility for control could be using the symbol table, I mean that exposed from the "nm" command, for defining what could go wrong and if it can be allowed. For instance that emerge operation could be blocked if it would affect initialization for some packages but allowed if it relates to some auxiliary functions |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Thu Sep 21, 2023 3:07 pm Post subject: |
|
|
Symbol table checks are not sufficient, and generally would help only if the affected packages are removing deprecated interfaces before their consumers have migrated to the new interface. This may happen, but the simple solution is to get the providing packages to keep the interfaces longer.
There is no need for a package to break its consumers. That only happens when the providing package's developers choose not to provide a clean migration path. If they choose not to do so, you cannot compensate for that lack with a more complicated dependency solver, because there is no valid path, no matter how clever the solver.
I think further discussion would require a more concrete example identifying what package(s) were a problem, why the manual fix worked (and the drawbacks it had), and from there we can discuss what a more clever solver could have done. |
|
| Back to top |
|
|
jeffss
n00b
Joined: 13 Sep 2019
Posts: 53
|
| Posted: Thu Sep 21, 2023 3:42 pm Post subject: |
|
|
| Hu wrote: | Symbol table checks are not sufficient, and generally would help only if the affected packages are removing deprecated interfaces before their consumers have migrated to the new interface. This may happen, but the simple solution is to get the providing packages to keep the interfaces longer.
There is no need for a package to break its consumers. That only happens when the providing package's developers choose not to provide a clean migration path. If they choose not to do so, you cannot compensate for that lack with a more complicated dependency solver, because there is no valid path, no matter how clever the solver.
I think further discussion would require a more concrete example identifying what package(s) were a problem, why the manual fix worked (and the drawbacks it had), and from there we can discuss what a more clever solver could have done. |
for the packages unfortunately I may need to wait until the next update, however something I had left out is that the exclude operation was not being sufficient to resolve the conflicts, I had to use some combination of nodeps and ignore-rebuild. What I did was using those flags for recompiling conflicting dependencies, recompiling the consumers, then recompiling both with along with some of the conflicting packages left out, maybe without the flags. It did work because on each cycle an ever greater number of dependency relations got solvable, (some even collateral, like when executed without the flags) at least among themselves, even though in relation with the full dependencies of the whole world upgrade they still did not; but after some repetitions eventually it was possible to have a globally solvable dependency resolution. The drawback is the number of rebuilds that may be necessary for the same packages, including for safety |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 21773
|
| Posted: Thu Sep 21, 2023 3:55 pm Post subject: |
|
|
| You should never need to use --nodeps. --exclude only forbids emerge from installing the specified atoms. If they are required by some other change, excluding them will probably cause an error. You should instead solve the problem(s) that prevent you from installing them. There is no --ignore-rebuild. Did you mean you are ignoring slot operators? That too may cause new problems. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
