On Wed, 2017-08-23 at 17:25 +0100, Richard Hughes wrote:
On 23 August 2017 at 13:57, Marius Vollmer
<marius.vollmer(a)redhat.com> wrote:
> In a modular repository, I think the same thing should happen so that
> GNOME Software can present interesting modules to the user in a nice
> way.
What kind of modules would be shown in gnome-software? Are
applications like Firefox going to be supported in the new modularity
system? We're not going to be showing httpd there for instance.
The current expectation is that the only way that modules are going to
show up in GNOME Software is when they are safely wrapped up as a Flatpak.
Because un-encapsulated modules can't be arbitrarily mixed and combined,
displaying them to users would add a huge amount of complexity.
> - Metainfo is in packages, but we need to be installing
modules.
How are we going to be installing modules in a modular-system?
PackageKit is only going to be able to install packages so
gnome-software will obviously need to be able to install things.
Via flatpak, not via PackageKit. :-)
> Thus,
> the collection data needs to have module names into the AppStream
> <pkgname> tag.
I think the pkgname tag needs to contain the package name. We have a
<bundle> tag that might be more suitable for adding things like
version or stream information.
yeah, the appstream provided via
registry.fedoraproject.org will have what to
install in the <bundle/> tag.
> 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.
appstream for modules is something that Marius is going to have to
eloborate on :-) For the desktop, the appstream data will be collected
from the Flatpaks uploaded to
registry.fedoraproject.org and made available
for download.
> - 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.
The way we've solved this in Flatpak is to use a different application
ID, for instance Firefox nightly would be
org.mozilla.Firefox.Nightly.desktop rather than
org.mozilla.Firefox.desktop
I don't think you can pretend that applications from different
branches (with different features, bugs and possibly UI) are the
"same" component, especially when you can install zero, one or many at
the same time.
The Flatpak build tooling currently enforces that the branch is the same
as the module stream, but allows the packager to use different IDs for
different streams if they want - so they can have a nightly and a stable
stream that can be parallel installed as above. (With caveats of needing
to modify application code appropriately.)
Owen