Richard Hughes <hughsient@xxxxxxxxx> writes:
> On 23 August 2017 at 13:57, Marius Vollmer <marius.vollmer@xxxxxxxxxx> wrote:
>
>> I propose to keep AppStream metainfo data in packages, and map from
>> package names to module names during construction of the collection
>> data.
>
> Can you elaborate a bit? At the moment in Fedora we generate the
> AppStream metadata from a mirror of all the packages using
> appstream-builder.
When creating the AppStream collection data for a modularized
repository, we might want to insert information about the modules that a
package belongs to into the collection data, maybe as a <bundle/> tag.
So we need to have a function that takes a package name and returns a
list of (module name, stream, profile) tuples.
(Alternatively, we could require that the modulemd data for a module
contains everything we need for the AppStream collection data. I was
proposing not to do this and just keep looking at the packages.)
>> - Because of streams and profiles, there can be multiple versions of
>> metainfo for a given AppStream component id. These need to be
>> merged
>
> No, I don't think they do. If you have two very different versions of
> Firefox (one LTS, one bleeding edge) you want a different description,
> different screenshots and different reviews.
Sorry, I wasn't clear. I shouldn't have said "merged".
If appstream-builder finds two packages that both contain metainfo for
the same component id, what does it do? 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.
One approach is just to put them all into the collection data:
<components ...>
<component ...>
<id>com.example.foo</id>
<name>Foo</name>
<pkgname>foo</pkgname>
</component>
<component ...>
<id>com.example.foo</id>
<name>Foo</name>
<pkgname>foo-nightly</pkgname>
</component>
</components>
This is what they do for Flatpaks if I understand Owen correctly.
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!
My proposed approach was to encode the exact same data via a spec
extension:
<components ...>
<component ...>
<id>com.example.foo</id>
<name>Foo</name>
<pkgname>foo</pkgname>
<variants>
<variant>
<variantsummary>Recommended</variantsummary>
</variant>
<variant>
<variantsummary>Nightly builds</variantsummary>
<pkgname>foo-nightly</pkgname>
</variant>
</variants>
</component>
</components>
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.
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.
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).
I am happy to just say that modularized repositories don't have
AppStream data, period.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
