-
Notifications
You must be signed in to change notification settings - Fork 50
Make it clear who packages flathub artifacts #214
Comments
I think the right way to handle this is an actual way to display if the package is maintained by the upstream developers. If not the case, just redirect the issues url to the github repository on github.org/flathub instead of the upstream one. A packager name doesn't make sense, because Flathub tries to avoid having a packager and just give all the keys to the developer to deploy their application and update it to all the users. |
I would say this makes less sense. You cannot say that you expect upstream to be the primary packagers when you yourselves are releasing third party packages (modified from upstream distributions at that). https://github.com/flathub/com.obsproject.Studio. How am I supposed to believe you? --- edit |
|
Just as with any form of binary distribution, you are either trusting whoever distributes it or not. Slapping name of person who is the supposed maintainer on it does not really change anything. You are accusing us of modifying upstream source (or so I understand), while Debian applies 8 not upstreamed patches, Ubuntu uses cryptic "Ubuntu MOTU Developer" and Arch mentions at least 3 other names in the change log. Snap links to their bug tracker – which isn't really far from what we're doing. Yes, we do ship a portal which allows users to use your project in the first place on distributions with Wayland enabled by default, but there's nothing in the license prohibiting from doing so. The application has been added Flathub before prerequisites for submissions were well fleshed out. These days we require submitters to reach out to upstream them whether they would be interested in maintaining their application on Flathub and proceed with addition only when 1) they are, 2) there was no response 3) they are not interested in packaging whatsoever. Not saying there's no room for improvement here. Your issue is already partially covered by #213. With clear designation which applications are upstream-maintained (also for these built on Flathub infra), we'll be able to display more useful in Publisher field. It's a process though, nothing happens overnight. P.S. Also yes, we're always happy to handover repository ownership for applications submitted by third party packagers. |
This is precisely the issue. Flathub.org is not clear on who is distributing packages. As evidenced by users coming to us asking us to fix it. That is why I have opened this issue.
Im only pointing out if your claim is How is this different from other packager managers I point out? Debian again has their own packages with their own bug trackers and make it clear to users this is the case via apt. They also appropriately modify versions reported by the application to denote its packaged by Debian and not an upstream package (https://salsa.debian.org/multimedia-team/obs-studio/-/blob/master/debian/rules#L18). Ubuntu mostly just pulling debian packages does the same. And provides the same transparency and facilities for their packages. Arch provides a way to contact the current maintainer, or provide comments and bug reports on the package. It would be preferable if they also marked their package versions. Im happy that people want to package obs on flathub, but I just want flathub.org to support transparency for users to know what they are getting, from whom, and how to contact the people who support it. Thats all. (The concept of "give all the keys to the developer" doesn't really fit with the open source model of software you are packaging on flathub IMHO. Maintainers come and go as seen on the arch linux packaging you note. This is another reason why transparency on packagers is needed on a package manager like flathub.org) |
Just to be clear we have our own bug tracker and it is linked the website. We can just work to make it more obvious. I believe everybody involved with Flathub wants that to happen. Nobody is trying to hide some details. |
I hope it doesnt sound like I am accusing flathub of trying to actively trying to hide this or anything so nefarious. I just think as it stands with the current UI design the end result is user confusion (more so than the typical linux packaging misunderstandings). |
Personally, more than making clear who's packaging the app, I would just like to know whether the original author is packaging it or not. Simply, an "official" checkmark. Or alternatively an "unofficial" label. Snap does it, and as a user my order of preference currently is: Official Flatpak -> Distro-specific package -> Unofficial Flatpak. This is not borne out of mistrust of the volunteers who package the apps, it's just easier to know who to blame if anything is wrong with the app, and in case of Flathub.org, gives it a little bit of additional legitimacy. |
Yesterday I played around a bit with how to implement around how to make this status more clear. Main issue currently remains where do we get this status from without requiring a manual approval process or alike, since everyone has more than enough to do. One could argue, that we should just trust the maintainer to be honest in that perspective, since we trust maintainers anyway. I'll leave this up to discussions, I'll also provide some screenshots later. |
One way to differentiate between developer-published packages and “community-published” packages could be to have the storefront check for a specific
Flathub could provide a similar template, along the lines of:
This
Obviously, anybody could unilaterally add this Does this seem like a reasonable approach to the specific issues people are presenting in this thread? |
Note: there’s an existing |
We have been talking about such "verified" badges in another issue #48 and so far, we didn't reach any consensus on how the verification should work. Main concern is: Maintainers also control the metadata and therefore could point it wherever they want. Which is why I pointed out that it's probably enough to just trust maintainers to be honest. However we might manage to make app-ids claimable through a verification process. That could be an idea, but in unrelated to this issue. |
Verification badges are now tracked in flathub-infra/website#44 |
Flathub.org is incredibly misleading about its packaging typically hiding the actual packagers under a link with no names attached at all. This continually causes users to think upstream is maintaining these broken third party packages.
The frontend should clearly identify (by name or other identifier) the packagers and make it clear where users can file bugs against the packaging.
https://tracker.debian.org/pkg/obs-studio (maintainers clearly identified)
https://packages.ubuntu.com/bionic/obs-studio (maintainer clearly identified)
https://snapcraft.io/obs-studio (About as bad as flathub, but at least packagers have the courtesy to mark their unofficial packaging and inform users where to file bugs recognizing the flaws of the platform they are distributing on.)
https://www.archlinux.org/packages/community/x86_64/obs-studio/ (maintainer clearly identified)
In case you somehow believe users are able to divine what your cryptic links and arbitrary naming of "publisher" mean, here is the most recent example of users being completely confused by this:
obsproject/obs-studio#2683
The text was updated successfully, but these errors were encountered: