top 50 comments

sorted by: hot top controversial new old
[–] 104 points 2 years ago* (4 children)

I feel like OP missed an opportunity to title this post “Fedora Flatpaks Fall Flat”

Great article, BTW

  • source
  • hideshow 4 child comments
  • [–] 27 points 2 years ago* (last edited 7 months ago)

    Great article, BTW

    I disagree, the headline is clickbaity and implies that there is some ongoing conflict. The fact that the Fedora flatpak package maintainer pushed an update marking it EOL, with "The Fedora Flatpak build of obs-studio may have limited functionality compared to other sources. Please do not report bugs to the OBS Studio project about this build." in the end-of-life metadata field the day before this article was written is not mentioned until the second-to-last sentence of it. (And the OBS maintainer has since said "For the moment, the EOL notice is sufficient enough to distance ourselves from the package that a full rebrand is not necessary at this time, as we would rather you focus efforts on the long-term goal and understand what that is.")

    The article also doesn't answer lots of questions such as:

    • Why is the official OBS flatpak using an EOL'd runtime?
    • Why did Fedora bother to maintain both their own flatpak and an RPM package of OBS?
    • What (and why) are the problems (or missing functionality) in the Fedora Flatpak, anyway? (there is some discussion of that here... but it's still not clear to me)
    • What is the expected user experience going to be for users who have the Fedora flatpak installed, now that it is marked EOL? Will it be obvious to them that they can/should use the flathub version, or will the EOL'd package in the Fedora flatpak repo continue to "outweigh" it?

    Note again that OBS's official flathub flatpak is also marked EOL currently, due to depending on an EOL runtime. Also, from the discussion here it is clear that simply removing the package (as the OBS dev actually requested) instead of marking it EOL (as they did) would leave current users continuing to use it and unwittingly missing all future updates. (I think that may also be the outcome of marking it EOL too? it seems like flatpak maybe needs to get some way to inform users that they should uninstall an EOL package at update time, and/or inform them of a different package which replaces one they have installed.)

    TLDR: this is all a mess, but, contrary to what the article might lead people to believe, the OBS devs and Fedora devs appear to be working together in good faith to do the best thing for their users. The legal threat (which was just in an issue comment, not sent formally by lawyers) was only made because Fedora was initially non-responsive, but they became responsive prior to this article being written.

  • source
  • parent
  • [–] 65 points 2 years ago (11 children)

    The issue is that they are pushing their own version of flatpaks, some of which are broken, instead of contributing to flat hub and making that the default.

  • source
  • hideshow 11 child comments
  • [–] 46 points 2 years ago* (last edited 11 months ago) (1 child)

    This comment should be deleted soon

  • source
  • parent
  • hideshow 1 child comment
  • [–] 23 points 2 years ago

    That honestly doesn't sound like a bad mission, but it seems like there's a couple other requirements they should impose on their mission and then there wouldn't be any controversy.

    They should require that their package works as well as the upstream, and, in the even that it doesn't, they need to be very blatant and open that this is a downstream package, and support for it will only be provided by Fedora Flatpaks, and that you may have better results with the official packages.

    The primary issues in this case is that it doesn't work, and it's not been clear to users who to ask for help.

  • source
  • parent
  • load more comments (9 replies)
    [–] 29 points 2 years ago* (11 children)

    What is the lesson we can learn here as stated by the author of the post?

    A messy situation but hopefully one some lessons can be learned from.

    There is no info why packaging failed. I can't draw any obvious lesson from this post

  • source
  • hideshow 11 child comments
  • [–] 35 points 2 years ago* (10 children)

    The lesson is that Fedora Flatpak Repo needs to fuck off. It's an anti-pattern to have an obscure flatpak repo with software that is packaged differently from everything else.

    The entire point of flatpaks was to have a universal packaging format that upstream devs could make themselves, and Fedora is completely undermining it.

  • source
  • parent
  • hideshow 10 child comments
  • [+] 24 points 2 years ago* (last edited 11 months ago) (4 children)
  • [–] 11 points 2 years ago* (2 children)

    They work on other distros... if they work at all. If those "strict guidelines" are resulting in flatpaks like OBS and Bottles, which are broken and the devs have tried to get them to stop shipping, then I'll pass on Fedora flatpaks.

    I dont criticize Flatpaks for allowing alternative packaging sources. I criticize Fedora for sneakily (whether intentionally sneaky or not) setting their broken flatpak repo as the default, leading to a bunch of confusion by Fedora users that don't know they're actually using different, sometimes broken, packages from everyone else.

    The uBlue downstreams of Fedora know this, and they have the decency to present the user with that information upon installation. So thankfully, their users don't end up wasting their time with problems that Fedora introduced.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (2 replies)
  • Honestly, that sounds great.

    My biggest problem with Flatpak is that Flathub has all sorts of weird crap, and depending on your UI it's not always easy to tell what's official and what's just from some rando. I don't want a repo full of "unverified" packages to be a first-class citizen in my distro.

    Distros can and should curate packages. That's half the point of a distro.

    And yes, the idea of packaging dependencies in their own isolated container per-app comes with real downsides: I can't simply patch a library once at the system level.

    I'm running a Fedora derivative and I wasn't even aware of this option. I'm going to look into it now because it sounds better than Flathub.

  • source
  • parent
  • load more comments (5 replies)
  • [–] 26 points 2 years ago*

    Ah I'm glad to see the situation seems to have cooled a little.

    See this comment and the three following, as well as this one and the two following. I think they can now work it out between the projects reasonably.

    PS: This more fundamental proposal for Fedora Workstation that started from the OBS packaging issue is also interesting to read. It seems they are looking to make more limited / focused use of their own Flatpak remote in the future since some old assumptions regarding Flatpaks and Flathub don't hold so well anymore.

  • source
  • [–] 12 points 2 years ago

    Obviously, the best solution is that the gets settled out-of-court. However, Fedora has had a long time to listen to the OBS devs' request to stop packaging broken software, so maybe they won't listen to reason.

    Fedora needs to get their heads out of their asses and kill the Fedora Flatpak repo.

  • source
  • [–] 6 points 2 years ago

    Totally forget that I still was in fedora's flatpak repo until the news dropped. Took the opportunity to remove and replace it with flathub.

  • source
  • [–] 5 points 2 years ago* (5 children)

    Is there any merit to the claim OBS is using an end-of-life (EOL) runtime and that this is a very bad thing for security?

  • source
  • hideshow 5 child comments
  • [–] 3 points 2 years ago (2 children)

    I think you might find this comment by one of the OBS upstream devs interesting:

    https://pagure.io/fedora-workstation/issue/463#comment-955899

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 2 years ago

    Fedora's opinion seems to be that upgrading is always the right choice, which we disagree with.

    Ugh, I'm glad people are willing to fight back against these kinds of assertions.

    Regardless of who is right, facilitating and encouraging this kind of discourse is how we end up with better software for everyone.

  • source
  • parent
  • [–] 5 points 2 years ago (1 child)
  • [–] 4 points 2 years ago

    It's not that hard to actually follow XDG specifications instead of hardcoding paths.

    Which flatpak itself doesn't, btw. $HOME/.var for flatpaks is hardcoded, no answer in the issue tracker so far, to the proposal of using the usual flatpak_xyz_dir variable to change the path.

  • source
  • parent
  • [–] 3 points 2 years ago

    inb4 Iceweasel

  • source
  • load more comments
    view more: next ›