Limiting what is in the appstream

[Alexander Larsson]

On ons, 2016-10-05 at 12:49 -0700, Dan Nicholson wrote:
> On Wed, Oct 5, 2016 at 7:25 AM, Alexander Larsson <alexl at redhat.com>
> wrote:
> > 
> > I have gotten requests from Endless about having a way to limit
> > what is
> > in the appstream branch, because they want to store all the apps in
> > a
> > single repo, but some apps are targeting an older OS version, and
> > some
> > a newer, and you only want to see the newer ones. Is that correct?
> 
> I'm not sure what the actual request was, but we might want to do
> something like that. The way we're handling the stable release is by
> adding a compat ref that points to the current minor series. I.e.,
> systems are setup to pull from the eos3 branch, but the eos3 branch
> head is actually just a copy of the eos3.0 branch head. Later when we
> move to eos3.1, the eos3 branch logic will be changed to follow that
> series. This is similar to what you might do with a "stable" vs
> "3.20", "3.22", etc in GNOME. I.e., pulling from the stable branch
> would always get you on the latest stable series.
> 
> Of course, the downside of this approach is that we have multiple
> copies of the same information in the appstream branch (and in the
> summary, but that's a different story). I.e., each app has appstream
> data for eos3 and eos3.0, but it's identical except for the bundle
> info. In my mind, we want to keep both refs (and eos3.1 ref when that
> series is created) so that you can legitimately install flatpaks from
> either an explicit minor series or the major stable series. Whether
> we
> need all that information in the appstream branch available to
> gnome-software, I'm not sure. Quite possibly we only want the eos3
> major series refs in the appstream so that gnome-software will only
> ever offer the current stable version to you. Advanced users could
> still install explicit minor series versions using flatpak directly,
> of course.

Talked a bit to cosimo and hughsie on irc yesterday, and it seems that
the canonical answer right now is to do all filtering on the client
side for now. I'll add a "default branch" property to the repository
(default from the summary file, can be overridden locally for the
remote configuration, basically like the title) that can be used by
gnome-software to figure out which branch to use/show by default.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a fiendish white trash cop with no name. She's a time-travelling 
wisecracking detective on the trail of a serial killer. They fight crime!