search

flathub-infra / linux-store-frontend

A web application to browse and install applications present in Flatpak repositories. Powers https://www.flathub.org
Apache License 2.0
187 stars 50 forks source link

Support apps that directly publish to flathub #213

Open nedrichards opened 4 years ago

nedrichards commented 4 years ago

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 commented 4 years ago

imatge

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 commented 4 years ago

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 commented 4 years ago

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

MihaiTabara commented 4 years ago

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 commented 4 years ago

@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:

jgarciao commented 4 years ago

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

image

barthalion commented 4 years ago

@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 commented 4 years ago

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

nedrichards commented 4 years ago

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

jgarciao commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

@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 commented 2 years ago

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.