Richard Hughes <hughsient@xxxxxxxxx> writes:
> On 24 August 2017 at 08:45, Marius Vollmer <marius.vollmer@xxxxxxxxxx> wrote:
>
>> 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.
Okay, that was my understanding of the spec as well.
>> 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?
The variantsummary is meant to be used in the UI element for selecting a
variant.
> Should reviews for the different variants be treated as the same thing
> or as different things?
I would say reviews for all variants should be associated with the
single component id. I guess reviews carry information about the
version of the component that they were made for already, and the same
mechanism could be used to say which variant they apply to.
> 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.
This is all optional. I am exploring what happens if a package with
AppStream metainfo data appears in a module, and I think I have sketched
out a path where we can do something correct/sensible with it that
doesn't require any changes to existing AppStream consumers.
A better path IMO is to decide that Software Centers don't want to see
naked modules when dealing with Applications, just flatpaks or other
containers. I wasn't sure that this is an acceptable option, but it
looks like it is.
>> 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?
One.
> Would you be able to switch between the variants?
Yes.
> Can both be installed at the same time, by two different users on the
> same system?
No.
>> 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?
This is a modularized repo, I think:
https://kojipkgs.fedoraproject.org/compose/26/Fedora-Modular-26-20170720.0/compose/Server/x86_64/os/
It does contain both
nodejs-6.10.3-2.module_9c237b2a.x86_64.rpm and
nodejs-8.0.0-1.module_42d8f2a0.x86_64.rpm
for example.
I hope the modularity people on this list can provide more details.
> Has anyone talked to the Fedora or GNOME designers about this?
I will talk to our Cockpit designers, of course, once everyone is back
from vacation.
> 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.
Well, I have learned a lot already from this discussion, so thanks for
that!
> 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.
This makes a lot of sense to me.
>> 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.
Sorry, again I should have been clearer: Instead of figuring out how to
make AppStream work with modularized repositories, we can also say that
we wont be installing applications as RPMs from modularized repositories
(only as flatpaks etc), and thus a modularized repository doesn't need
any AppStream data (period) and we don't need to figure out how the make
that work.
However, the general concept of variants of a single applications and
letting the user choose between them is a good one, no? Firefox
Regular, Firefox Nightly, and Firefox Fatfree _are_ related to each
other and we can do better than just showing them next to each other in
a list, no?
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
