Add a new API to set resolvables for installation#2859
Add a new API to set resolvables for installation#2859imobachgs merged 10 commits intosoftware-servicefrom
Conversation
* Introduce a new Resolvable type which contains a name and a type.
* It is an private API for other Agama services to ask for the installation of a given resolvable.
* Use a HashMap to keep the resolvables lists. * Remove the "optional" argument because it is not used. * Re-enable and fix the tests.
imobachgs
force-pushed
the
software-selection
branch
from
38d15f0 to
194a671
Compare
| // TODO: consider implementing a list to make easier working with them. | ||
| pub patterns: Vec<ResolvableName>, | ||
| pub packages: Vec<ResolvableName>, | ||
| pub resolvables: Vec<ResolvableState>, |
There was a problem hiding this comment.
Sorry, I do not get how this can work with just list of resolvables. There is no ID for them, right? How it can know how to transit between different states? I have to admit it starts to be more and more magic for me with so many different transitions of data to different states.
There was a problem hiding this comment.
Actually I would say it is quite the contrary: we add patterns, packages, repositories, etc. At this point, you do not care about the list of resolvables (with the ID). You just need a set of things to get installed, and whether they are optional or not.
So the SoftwareState (I would rather prefer a better name, but it is the name we used for NetworkState) just tells you what you want to get in the system: repositories, packages, product, etc. And the Adapter, instead of having a lot of individual and small methods, just takes care of making it a reality. In a single place.
The workflow is like this:
- The SoftwareStateBuilder puts together the information from all the sources (current system, configuration, etc.) . I need to include the SoftwareSelection in the docs, but it is mostly documented.
- The resulting
SoftwareStageis send to theModelAdapter, which takes care of synchronizing zypp state.
There was a problem hiding this comment.
so basically idea is that will unselect all resolvables ( which is not done now ) and then reselect everything again from scratch, right?
There was a problem hiding this comment.
Yes, I will address that in a separate PR. We might need to extend the wrapper too.
There was a problem hiding this comment.
Having said that, you do not need to reset everything from scratch, just to make sure that you sync the changes (adding the missing packages, removing the ones you do not want, etc.).
2 participants
Problem
Some Agama services need to ask for the installation of some resolvables.
Solution
This PR adds a new private API that allows selecting resolvables for installation. The new end-point is
PUT /api/v2/private/resolvables/:idand receives the list of resolvables:[{ "name": "btrfsprogs", "type": "package" }]Testing