On 24 August 2017 at 08:45, Marius Vollmer <marius.vollmer@xxxxxxxxxx> wrote: > If appstream-builder finds two packages that both contain metainfo for > the same component id, what does it do? If I understand correctly, in appstream-builder it's an error, and the "first encountered" component wins. > What should it do? What should > the Software Center do. This isn't described in the AppStream spec > beyond the "merge" and "pripority" attributes for the <components> tag. You have to remember, the AppStream spec was initially designed as a way to map application IDs to package names. AppStream metadata is written by basically every distro and consumed by every software center, and it's not Fedora specific, so you probably shouldn't be super surprised it doesn't map into the Fedora modularity system very well. My personal feeling is that this whole modularity initiative is being pushed hard into all layers of Fedora without actually working out how this is going to work with the various upstream specifications and projects. I'm sure it'll be great for Fedora in the short term, but longer term it's going to hurt being a little island of Fedora-specific schemas and tools. > One approach is just to put them all into the collection data: You can't have two components with the same ID inside a <components> group with the same origin. > This is what they do for Flatpaks if I understand Owen correctly. No, flatpaks components have different <id> names for each different branch. e.g. the org.mozilla.Firefox.Nightly.desktop thing I explained in my last email. > I had assumed that the spec doesn't allow this and I thought that > changing it to allow it would be too drastic. If this is established > practice and we just need to update the spec to catch up with reality, > great! No, please can you re-read mine and Owens previous emails please. > My proposed approach was to encode the exact same data via a spec > extension: > <variants> > <variant> > <variantsummary>Recommended</variantsummary> > </variant> > <variant> > <variantsummary>Nightly builds</variantsummary> > <pkgname>foo-nightly</pkgname> > </variant> I'm sorry, but that makes almost no sense. What is the software center supposed to do with variantsummary? Is the application name the same between the two variants? Should reviews for the different variants be treated as the same thing or as different things? To me a module is a superset of a set of packages, much like a <component> -- so it would make sense to have something like <id>org.fedoraproject.modularity.http2-6</id> which contains the translated name, the translated description, the SPDX license, and any URL links too. Of course, this is mostly the same as the modulemd metadata as specified https://docs.pagure.org/modularity/development/building-modules/developing.html so you can certainly create AppStream from that pretty easily. I don't think it makes any sense at all making projects like GNOME Software, Apper, Discover, Muon and Cockpit (and others) understand much about the Fedora modularity stuff when everything seems to have standardized on AppStream -- including next-generation distributions methods like Flatpak. > If a client understands "variants", it can trivially expand them back > into multiple entries for the same id. Clients that don't understand > this will continue to just see one. They're two different things. Would gnome-software and cockpit show two search entries for the two variants or one? Would you be able to switch between the variants? Can both be installed at the same time, by two different users on the same system? If the modules are flatpaks then they're two different components with two different AppIDs, that can both be installed at the same time. I'm having a very hard time working out how we'd communicate difficult to understand concepts to the end user using packages, even wrapped up with modulemd metadata. > Maybe I should emphasize that I am only trying to figure out what > happens if we subject a modularized repository to the usual AppStream > treatment. Can you provide some specifications on what a modularized repository should actually look like please? Is a repo going to contain .rpm packages like firefox-1.23.rpm and also firefox-2.34.rpm or something completely different? If both packages contain a metainfo/appdata file with the same component <id> it's just not going to work very well using appstream-builder. > I think we would create broken AppStream collection data right now, or > at least AppStream data that doesn't let us take advantage of the new > features that modularity enables (streams and profiles). Has anyone talked to the Fedora or GNOME designers about this? I'm trying hard not to get frustrated about questions about XML schema when I don't think anybody has considered the user experience of modularity. From a desktop point of view I'm currently of the opinion that it only makes sense to show modules that are flatpaks, and continue to use the appstream branch of the flatpak repository to get information about the modules. > I am happy to just say that modularized repositories don't have > AppStream data, period. Why are you happy they don't have AppStream? I'm not sure trying to antagonize the people involved is a very good idea at all. Richard _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
