Open ignatenkobrain opened 5 years ago
They probably can be considered along the lines of mutually conflicting sub-repositories. If we tied them that way, we could leverage the vendor locking mechanism in the same manner to "lock" to streams. There'd need to be some additional fiddling to handle forced stream transitions, but that might be a good foundation to start from.
There's some piece of the code which handles conversion to a modules here: https://github.com/fedora-modularity/fus/blob/master/fus.c#L23-L333
Why do you think there's something wrong with #296 ? It just includes the data from the updateinfo file. You can argue that the updateinfo xml design is bad, but this doesn't belong here.
As an author of modular implementation in DNF I would like to participate in discussions. I hope that we will be able to find out a compatible implementation with DNF.
So in Fedora there is thing called "Modularity" which are essentially a groups of packages which conflict with the other groups with same name.
For example, libgit2:0.28 contains libgit2-0.28-1 and libgit2:0.27 contains libgit2-0.27-1 which can't be installed at the same time.
Those modules have build flavor (e.g. it might be built against different versions of a dependencies) but still have same name and stream and version.
I would love to have some better design of whole thing instead of accepting some random half-baked patches like #296.
That said, in MBS (Module Build Service) we create additional solvables for each module and add dependency from respective rpms to them. And mark modules to conflict with each other.
This is definitely not the best way, probably we need some special code which would do all this matching internally (pretty much like namespaces work). I'm not sure.
/cc @mlschroe @Conan-Kudo @dmach