WIP - Variants #132
Closed
WIP - Variants #132
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@hughsie, fyi. |
|
Variants might also be useful re AppStream data for container images (including flatpak), I think. The "tags" in a Docker registry are roughly equivalent to Modularity "streams", I think. |
|
It seems to be too early to try to figure out in detail how AppStream and Modularity can be made to fit together, so I closing this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Hi!
I am pondering whether to propose adding "variants" to AppStream, and imo pull requests are not the worst medium for discussing ideas, so I have opened this one.
So, the motivation for this is the "Modularity" effort of Fedora: https://docs.pagure.org/modularity/
From the point of view of a Software Center, modularity adds two new concepts: stream and profile. In addition to deciding which component to install, a user also can decide from which stream to install it, and which of its profiles. I think we should somehow represent these concepts in AppStream.
A modularity stream follows a major upstream version, such as "nodejs 6" vs "nodejs 8". A modularity profile represents a different "use case" for the component, such as "devel" vs "runtime" where "runtime" doesn't install docs or devel bits.
(Personally, I think there isn't super much experience yet with these concepts. I can see how streams are useful for applications, but profiles maybe not so much...)
A package repository that is has modularity modules in it might thus have multiple instances of metainfo data for the same id. One solution would be to allow multiple components in the collection data for the same id, but I think removing such a basic property of the schema is a bit brutal.
So, what about "variants"?
Existing Software Centers can just ignore them. The AppStream tools that collect data for a Fedora repository would need to be changed to merge multiple metainfo for a single id.
Modularity has two dimensions for variation: stream and profile. I propose to have only a single dimension of variants, because making this general for N dimensions is just too complex.
For the example, this means we get four variants: "nodejs 6 devel", "nodejs 6 runtime", "nodejs 8 devel", and "nodejs 8 runtime". I hope we can keep this under control but just not putting AppStream data in different profiles. If profiles turn out to be genuinely great, we can add hints so that the Software Center can factor the variants again into a multidimensional UI.