The appdata file needs to be the same name as the desktop file.
I don't want to rename the desktop file as that breaks favorite apps and requires workarounds in gnome-shell.

I don't quite understand why flatpak-builder needs org.gnome.Weather.xml, but anyway it should not be renamed in the json file.

Yeah, I got that impression as well that this was not right after some testing today, sorry for the confusion.

Another possibility could be to change the ID in the flatpak file to be org.gnome.Weather.Application so that it matches the app's ID and then everything should be fine. Or maybe it's fine to fix flatpak-builder to work fine with the org.gnome.Weather.Application.appdata.xml file (e.g. check for <id>.*.appdata.xml) when exporting the appstream data.

I'm adding Alex to CC in case he has an idea of what the best solution would be.

In a flatpak app, we generally want dbus name == desktop file name == app id. In fact, the way flatpak disallows exports of files with a different prefix than the app-id sorta enforces this.

Now, flatpak *does* allow you to export subnames of the app id. The idea being that if you have org.my.App, then you can also export org.my.App.Helper, and still avoid namespace conflicts etc.

This means org.gnome.Weather as app-id and org.gnome.Weather.Application as dbus name *works*. However, as you noticed the appstream-reading code in flatpak assumes the appstream file is exactly the app id, not sub dbus subname, so this is not working perfectly. Unless you *also* own org.gnome.Weather and/or org.gnome.Weather.SomethingElse i think the proper fix would be to use org.gnome.Weather.Application for the app id.

Thanks for the feedback, that's exactly the same conclusion I ended up getting to: renaming the app ID in the flatpak JSON file to org.gnome.Weather.Application.

@Giovanni @Alex Mind if I push a commit to gnome-apps-nightly to change that?

(In reply to Alexander Larsson from comment #3) 
> This means org.gnome.Weather as app-id and org.gnome.Weather.Application as
> dbus name *works*. However, as you noticed the appstream-reading code in
> flatpak assumes the appstream file is exactly the app id, not sub dbus
> subname, so this is not working perfectly. Unless you *also* own
> org.gnome.Weather and/or org.gnome.Weather.SomethingElse i think the proper
> fix would be to use org.gnome.Weather.Application for the app id.

That's the problem: the app owns org.gnome.Weather.BackgroundService (for the shell search provider).

This was designed with flatpak (well, dbus namespacing) in mind. If flatpak breaks with what is, to me, a reasonable design, flatpak should be fixed.

You can make the flatpak app to own that extra bus name in the JSON file via the finish-args arguments, so that should not be a problem if we were to change the app ID for flatpak to org.gnome.Weather.Application.

Other option that come to mind, though, in the flatpak side of things could beto relax a bit the matching rules in flatpak for tha <app id>.appdata.xml file, so that it would also accept something like <app id>.*.appdata.xml.

What do you guys think? Alex, if you think the second approach is fine, I'd be fine volunteering to make a PR for that.

This said, I want to clarify that I still think the right approach is to rename the flatpak to org.gnome.Weather.Application + own that extra D-Bus bus name in the JSON file, but I wouldn't want to just say that without giving alternatives.

If you also own org.gnome.Weather.BackgroundService then the app has to be org.gnome.Weather. However, the desktop file could still be org.gnome.Weather.desktop. There is no need for the .Application suffix.

Alternatively we could make flatpak read all appdatas with the app-id prefix. Maybe that makes most sense in this case. It would be great if you could look into that mario.

(In reply to Alexander Larsson from comment #8)
> If you also own org.gnome.Weather.BackgroundService then the app has to be
> org.gnome.Weather. However, the desktop file could still be
> org.gnome.Weather.desktop. There is no need for the .Application suffix.

Ah, ok. Btw, jftr, at the moment GNOME Weather's desktop file is org.gnome.Weather.Application.desktop already, and my understanding is that Giovanni doesn't want to change that. 

> Alternatively we could make flatpak read all appdatas with the app-id
> prefix. Maybe that makes most sense in this case. It would be great if you
> could look into that mario.

Sounds good to me, I can probably look into this tomorrow or Friday. Expect a PR soon.

Actually, and going back to the description of this bug, I think the best solution is actually easier and cleaner than all this:

Simply add "rename-appdata-file": "org.gnome.Weather.Application.appdata.xml" to the JSON file, run flatpak-builder in a system with appstream-compose installed, and it will do the right thing:

I've tested this locally by running flatpak-builder manually, exporting to a local repository, configuring it as a remote, pulling the appstream branch for it and then running GNOME Software... and I can see the Appstream data finally showing up in there. And I double-checked that the actual appstream.xml.gz file is on disk under /var/lib/flatpak/appstream/<local-repo>/x86_64/active, and it's there, so I think that's actually all that's needed.

I actually tested this as my first approach but then change my mind and completely forgot about this option after reading this comment from Giovanni:

(In reply to Giovanni Campagna from comment #1)
> The appdata file needs to be the same name as the desktop file.
> I don't want to rename the desktop file as that breaks favorite apps and
> requires workarounds in gnome-shell.
> 
> I don't quite understand why flatpak-builder needs org.gnome.Weather.xml,
> but anyway it should not be renamed in the json file.

After this conversation here, and going now in detail with the code and gdb through how flatpak-builder and flatpak build-finish process this file, I really don't understand what's the problem of renaming this file at the time the bundle is created, since this does not affect the application at runtime at all:

It only affects how the flatpak bundle is built, whether the appstream data gets processed by appstream-composed and placed where it's expected to be so that the contents can be merged into the appstream.xml.gz file that bundles the Appstream data of all the apps, that will live in the appstream branch of the repository.

So, and sorry for messing around so much with this, I think the actual best solution for this particular case is what I mentioned initially in the description of this bug: just use rename-appdata-file to make sure the right filename is bundled, so that appstream-compose can do its job.

Any objections? If not I'll push a small patch to the gnome-apps-nightly repo.

As additional information, after checking my local notes about the experiments I did on Endless with that approach of using rename-appdata-file, I noticed I've observed some problems when I did that that I blamed on having an flatpak app-ID different than the actual application's ID, which also partially discouraged me, together with Giovanni's comment, from keeping insisting on that route.

But I've just build flatpak from master on a Fedora 25 machine and ran the whole process there as described in my previous comment and the GNOME Weather is perfectly built, exposed to GNOME Software and works just fine, so it might be that we had some other problem in Endless (or in the older version of flatpak used there) when I tested this that made it fail.

All in all, unless someone sees a problem with the rename-appdata-file approach, I believe that's the way to go.

Let me know what you think, the sooner we merge this small change to gnome-apps-nightly, the sooner we'll have it ready in the stable repo so that we can re-test this again (also from Endless).

Thanks, and apologies for the long comments

Ping?

Apologies for not getting back to this sooner (I don't really have many cycles for gnome weather these days).

If the rename-appdata-file approach works with no other changes, I'm ok with it. It probably means that appstream-compose changed so it doesn't require the appdata file has the same name as the desktop file, which is a good thing.

It might also be worth investigating if we can do the rename upstream instead of the json builder file, but it's not a big deal.
Also, gnome-weather ships a json file for flatpak-builder too. Is there any plan to minimize the differences there?

Thanks for working on this in any case.

(In reply to Giovanni Campagna from comment #13)
> Apologies for not getting back to this sooner (I don't really have many
> cycles for gnome weather these days).

No worries, thanks for replying.

> If the rename-appdata-file approach works with no other changes, I'm ok with
> it. It probably means that appstream-compose changed so it doesn't require
> the appdata file has the same name as the desktop file, which is a good
> thing.

I just did yet another test now in the gnome-3-22 branch of gnome-apps-nightly and I can confirm renaming does the trick, so I just pushed this commit to master: https://git.gnome.org/browse/gnome-apps-nightly/commit/?id=c7fab5f5bb435084d47a23b7fa5eaa7df06163cb

> It might also be worth investigating if we can do the rename upstream
> instead of the json builder file, but it's not a big deal.

I've checked upstream and all the files are named the same way, and I think it would be a bit awkward to make an exception with this one just for flatpak when the rename-appdata-file mechanism will achieve exactly the same thing.

If anything, I'd consider renaming all of them to org.gnome.Weather, but you already stated you don't want to change the desktop file, so I think this solution is fine.

> Also, gnome-weather ships a json file for flatpak-builder too. Is there any
> plan to minimize the differences there?

My understanding is that, in the long run, the idea is that every app developer will take care of the way to bundle their respective applications, and so the JSON files would probably live in the appstream repos, and used from some centralized place (e.g. flathub) where the apps would be built and delivered from.

When that happen, you'd probably want to take a close look to the files in both places and merge them in one single file, I believe.

> Thanks for working on this in any case.

You're welcome. We are exploring at Endless the option to give users the possibility of installing apps from the GNOME repository by pre-configuring them in some images, and GNOME Weather is one of the apps we'd like to ship, and even pre-install. Hence the so much interest in this task :)

For the sake of completeness, a recent commit in GNOME Weather has implemented the original suggestion here at the same time that it did the required changes for the FlatpakManifests initiative, so the previous solution is basically obsolete now.

Thanks for doing that, Giovanni!

[1] https://git.gnome.org/browse/gnome-weather/commit/?id=3e00c286cf0adce8c7e5f181aefaff38bf1f0f32
[2] https://wiki.gnome.org/Initiatives/GnomeGoals/FlatpakManifests