Support apps that directly publish to flathub

[nedrichards]

Firefox is the first app that directly publishes to flathub, as such it doesn't have a github repo so the link there fails (https://github.com/flathub/org.mozilla.firefox/graphs/contributors/ does not exist). We need another path for direct publish apps like these.

There's a Mozilla bug about this as well that should be notified: https://bugzilla.mozilla.org/show_bug.cgi?id=1627831

[jgarciao]

The Developer field is empty because the <developer_name> is not present in the appdata

As @barthalion wrote, flathub.org's website calculates the Publisher url for all the apps based on their app id. The original idea was to be able to see the github usernames of the people maintaining the app at flathub.org

This is the first application that doesn't follow this pattern so it doesn't work properly as you saw...

While we think of a better solution, I can make a quick hack for Firefox and show the value "Mozilla" on both fields and, in the Publisher case, make it a link to https://www.mozilla.org/firefox

Works for you?

By the way, that is this repo? https://github.com/flathub/org.mozilla.Firefox.BaseApp

[barthalion]

No, this is a base app. Mozilla builds Flatpak in docker container with raw flatpak commands.

Using custom <metadata> tags and some explicit flatpak tag (upstream-maintained) is probably the best way to have custom Publisher field. I'll be looking into that.

[barthalion]

(Mentioning this as we probably want upstream-maintained applications to overwrite Publisher URL to indicate it's not downstream packaging.)

[MihaiTabara]

If there's anything we need to update in the flatpak, I'm happy to update that on our side. As to the correct contributors URL within https://flathub.org/apps/details/org.mozilla.firefox it should point to https://www.mozilla.org/credits/ instead.

[jgarciao]

@barthalion I think it's better to make a workaround for Firefox now and plan better how we implement this. As mentioned in #146 and #48 if an app is comming from upstream or not is an information that shouldn't come from the appdata, as package maintainers can do anything including control the metadata

@MihaiTabara the Publisher field is more to say who is publishing this software at flathub.org. not who made it.

In my opinion we have to:

• add to the database a new table with publishers (name, url, description, ...)
• create another table that links publishers with apps
• add to the website https://flathub.org/publishers/UniqueIDOfThePublisher similar to this https://play.google.com/store/apps/dev?id=7083182635971239206
• In the app description pages, in the Publisher field link to the previous page
• Create a publisher called "Flathub Community" or similar for apps not maintained by upstreams
• Create a little web application for flathub admins to create publishers and link apps to them

[jgarciao]

Yesterday I published a workaround for the firefox page not to have a broken link

[barthalion]

@barthalion I think it's better to make a workaround for Firefox now and plan better how we implement this. As mentioned in #146 and #48 if an app is comming from upstream or not is an information that shouldn't come from the appdata, as package maintainers can do anything including control the metadata

Well, not exactly. Appdata is the only place we can keep information like this. As we're handing out flat-manager tokens only trusted vendors, there's no concern here; for everyone else, upstream-maintained tag whitelist is managed by buildbot and is not accessible in any other way.

This is also somewhat moot given applications can ship anything in their appdata as we don't do any pre-moderation of that other than initial submission review.

[jgarciao]

I didn't know there was a upstream-maintained whitelist. That could help implementing #48 and #146

[nedrichards]

The workaround was shipped as part of linux-store-frontend 0.7.5. Worth keeping the issue open for the wider conversation?

[jgarciao]

I was doubting about closing the issue and finally I kept it opened in order remember to develop a better solution.

Alternatively we could write this requirement in a list of requirements for a future infrastructure

So, whatever you prefer will be fine

El dt., 14 d’abr. 2020, 19:13, Nick Richards [email protected] va escriure:

The workaround was shipped as part of linux-store-frontend 0.7.5. Worth keeping the issue open for the wider conversation?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/flathub/linux-store-frontend/issues/213#issuecomment-613568220, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAQKTUDV3BXVS2VWZSANHTRMSKTFANCNFSM4MEFODIA .

[pabl0]

There was an updated version of org.mozilla.firefox flatpak published yesterday. Say I want to see what was changed on the manifest, where should I go to? The broken github link in flathub was replaced with just the static string "Publisher Mozilla" and finding the relevant mozilla code repository seems incredibly difficult.

I think it would be okay for non-technical users to have a "publisher" link pointing to some generic corporate website, but it is still essential to have an easily discoverable link to the actual version control repository of the manifest. Especially since, unlike e.g. traditional Debian packages, flatpaks don't seem to have any concept of a changelog, so the transparency is somewhat poor.

[EchedelleLR]

@pabl0 I think similarly to the repo where the maintenance is made. I don't see any reference here. Maybe I should check Mozilla own public repos to see.

Updated: I found this from the mirror here: https://github.com/mozilla/gecko-dev/tree/master/taskcluster/docker/firefox-flatpak

[wjt]

I arranged for Firefox to have <developer_name> in https://phabricator.services.mozilla.com/D126583 so at least that part of the workaround could be reverted.