TIL Fedora is packaging a web browser app I developed for elementary OS, stopped updating over three years ago, and marked as end-of-life two years ago—yet it happily shows up in Fedora 40 if you search my name. It crashes on launch, so it doesn’t even work…
WHY??
Edit: I guess the package is being EOL'd in Fedora due to it no longer building and this thread, huzzah! My recommendation to distros: don’t package random apps and then not maintain them/communicate with upstream.
@alatiera ha, now I want to get it running just for giggles. I recall I did a tiny bit of work to make it look better (basically so it could be used on Pop!_OS by a friend), but yeah… I was not actively testing that.
@bashfulrobot I would love to bring some its ideas to GNOME Web or maintain a minimal Flatpak version or something in the future, but I just don have the time. I think @isantop had something similar in the works??
@adamw I'm just shocked that it's been sitting there in Fedora, with my name on it, unmaintained three years after I stopped updating it and two years after I explicitly marked it as EOL. And there's no easy way to tell that from Software on Workstation. 😬
I shouldn't have to create a bugzilla account and comment on a random issue to make it clear that it is entirely abandonware and irresponsible to ship to users.
@cassidy@adamw You don't have to create a bugzilla account. You can email <package>-maintainers@fedoraproject.org to reach the maintainers of a package.
@carlwgeorge@adamw thanks! I'll do that. I'm still just surprised by the situation considering it was clearly abandoned & archived.
To turn this into a positive thread/suggestions, maybe:
• Package building scripts should check if the source repo is archived, and not build it and/or amend the appstream to mark it as EOL
• GNOME Software could better expose when a package is that outdated
• Fedora should amend the appstream when an app is unsupported by the developer, like you see on Flathub
@cassidy@adamw Unfortunately none of those suggestions would have helped in this case. Fedora builds don't download upstream tarballs directly. The maintainer downloads the tarball from upstream once and uploads it to Fedora's "look aside cache", which is what the build system uses during package builds. The last time the package version was updated was in 2021, the day after the last tagged version, at which time I'm assuming the GitHub repo was not yet marked as archived.
@cassidy@adamw Future rebuilds for new Fedora versions continued to use the same cached tarball without checking GitHub. The builds kept passing until the F40 rebuild. That failed build was probably the first indication to the maintainer that something was awry, and it appears they just didn't have time to investigate it before the F40 release.
@cassidy@adamw As is usually the case, there just isn't a real substitute for upstream and downstream communicating, ideally in official channels like issue trackers, not on social media where it may or may not be seen.
@carlwgeorge@adamw I wouldn’t have even known where to have this discussion on an issue tracker—I stopped updating it over three years ago and archived it two years ago. I think the issue stems from the fact that the app was packaged and “maintained” against the wishes of the upstream by someone clearly not doing the maintenance work. For something as critical as a web browser, that just seems flawed out of the gate.
@carlwgeorge@adamw If none of the above would have helped, then Fedora’s packaging policies should be revisited. Because this should not be an acceptable outcome.
It’s tiring to be told, “hey you should go out of your way to come into our community and co-maintain your app that you don’t want to maintain for this platform/packaging format/etc.” but that’s exactly what happens when distros, Snap, etc. package my stuff. The burden falls on me to support it when I never intended to.
@carlwgeorge@adamw I only happened to realize this because I was testing something on Fedora Workstation 40 and saw it when searching for a different app of mine. Otherwise I’d have never known it was shipping to people, in Software, under my name, with no indication of it being unsupported/outdated.
Even short of that, an initial post on social media like "what's the best way to contact the maintainer of a Fedora package" would have been more appropriate than how this was handled.
"Against the wishes of the upstream" is not a fair statement. If the software is open source, distros can package it without permission. Upstreams can and do close bugs for platforms they don't care about.
@carlwgeorge@adamw I mean, I went to social media to vent because I was surprised and didn't even know where to start. I was given an email address, so I've sent an email to it if you want to move this to a mailing list instead.
That said, I don't really have anything else to add. I'm not interested in being told how to Google things or how to use social media.
@cassidy@adamw Venting on social media without communicating with the package maintainer first is not nice. It comes off as shaming the entire project, even if that wasn't your intent. You are of course free to use social media however you like, just as others are free to reply on social media that they don't like how you handled a situation.
Your excuse of "I wouldn’t have even known where to have this discussion on an issue tracker" is weak, which is why I mentioned doing a basic search.
@carlwgeorge@adamw dude, I posted a two sentence post at 11 PM while dicking around with the new Fedora 40 on my couch before going to bed.
I am not in the Fedora community. I don’t know (or really care) how package maintenance works in Fedora. I did not suddenly feel the need to investigate the ins and outs of the Fedora project before sharing my shocking (to me) discovery.
@carlwgeorge@adamw And then I wake up to replies from several Fedora folks that all I had to do was follow this specific Fedora process documented on Bugzilla, I’m “attacking” the maintainers, my “excuse” is “weak,” me communicating my wishes is “not fair,” my communication is not “appropriate,” I should have used an issue tracker or scoured the wiki to understand who to email…
I’ve shared my thoughts and wishes. It sounds like it’s being taken care of. I don’t need a lecture, too.
@cassidy@carlwgeorge uh, I feel like you're unfairly conflating mine and Carl's replies there. I didn't say you were attacking anyone, or anything about excuses, or fairness, or appropriateness. I just answered your question of why this was the case (by referring to the policies on retiring packages), and explained how it can be sped up, then I went ahead and did that for you. I hope that was useful.
I was not referring to you specifically @adamw; you’ve been very helpful. Thank you!
I’ve received replies from others (including I think maybe the package maintainer?) and @carlwgeorge that included what I quoted there. I was replying directly to Carl’s post.
@berkough I would be happy for someone to actually take the idea and make something decent from it. But I discontinued it because it didn’t really work well in a Flatpak world plus it was way over my head for responsible maintenance.
I didn’t even know it was being packaged by Fedora, let alone just there in the app store in Fedora 40.
@cassidy@berkough That's definitely happened a number of times before - where an upstream thing gets orphaned and a very heroic Fedora maintainer keeps it patched and going for years. It's also entirely possible that a maintainer saw the rpm build didn't fail and never actually tested it and no one else filed a bug about it during the beta. The level of commitment varies wildly.
@cassidy Nothing wrong with that. That's the nature of open source. As long as everyone is aware that it's not a maintained piece of software, all's fair in love and code.
@berkough nothing about the app listing lets you know it is unmaintained. To the contrary, it shows as a “Safe” app developed by me, provided by Fedora. It contains my app description that I wrote for it on elementary OS. You have to click into the detailed version history to even see how long ago it was last updated (3 years ago!).
@cassidy@berkough The "safe" listing is something that really needs to be reconsidered on all the application stores that use it. Unless it's been verified safe, any arbitrary code has the potential to be unsafe and it just gives a false sense of security
@BrodieOnLinux@berkough GNOME upstream is much more nuanced, but yeah, I am starting to think we should not have a “safe” badge at all if stuff that is safe gets downgraded for reasonable permissions while a three-years-outdated unmaintained web browser packaged against its developer's wishes that crashes in launch is considered “safe.”
@cassidy@berkough My main issue with it is even if something is completely sandboxed it could still direct the user out to an external web resource for a phishing attack for example. I get the logic behind having a simple way to point out the permissions being used but "safe" comes with a lot of baggage
@BrodieOnLinux@berkough right which is why part of the equation is developer verification, human review of app submissions and permission changes, and a more nuanced safety rating that takes into account network access—all the case with Flathub + GNOME.
Buuuut even then it seems like it would be easier not to promise safety, but to warn on more critical potential issues.
@cassidy@berkough Promising safety is a problem because the second that something slips through the cracks it won't just be the developer that is blamed, it'll be the store for failing to properly review it when it was called safe. By promising safety you are taking on a much more important role than just app listing, now you're curating apps and have the responsibility to do that job properly.
@cassidy@berkough When it comes to potential permission issues there's also the problem of how to display that information without overloading a user but I feel that's less critical to get right than a false sense of safety
@BrodieOnLinux@cassidy Disclaimers don't have to be SCARY, they can simply state when the source code was last updated, and that the older a piece of software is, the less likely it is to work as intended, or at all.
Add comment