Hi Richard, I'm, a CHIRP user (even spotted Dan some cash) and I would love to see it it Fedora since it's "gateway app" for some many new HAMs. I didn't know this was a problem and I would welcome an opportunity to help. Feel free to contact me (blaise at gmail)
Neal, Thanks for the info on Fedora Flatpaks, I didn't know there was a difference! -Blaise On Mon, Apr 13, 2020 at 4:18 PM Neal Gompa <ngomp...@gmail.com> wrote: > On Mon, Apr 13, 2020 at 6:53 PM Richard Shaw <hobbes1...@gmail.com> wrote: > > > > So with Python 2 being fully removed (more or less) with Fedora 32, > Fedora 31 is the last version that will contain Chirp, which is an > important and the ONLY tool for Amateur Radio operators to program radios > in linux. > > > > Don't get me started on upstreams lack of interest on correcting the > issue... > > > > So I decided to look at flatpaks as a method of making it available post > Fedora 31. > > > > 1. The documentation sucks. You see code snippets everywhere and it's > not clear what section it belongs in the json file, which leads me to #2. > > > > 2. JSON may be fine for machine readability but it SUCKS for human > readability. Both brackets and braces! Do I need a "," after that one? All > I know is I screw around with it until vim doesn't show me any more red > highlights. > > > > Yes, you can do YAML instead, which is FAR more readable, but MOST of > the examples are in JSON. > > > > 3. I understand the names (app-id) need to be unique, but how about some > better guidance on how to name them! > > > > 4. Examples show you how to execute "pip..." to install python > dependencies, but they don't show you what you need to include SDK wise so > a python interpreter is available! I've googles references that you need > the correct SDK, but "flatpak search" doesn't return those. > > > > You've more or less hit the nail on the head for why I've personally > not been interested in Flatpaks. There's definitely some cool > technology there, but clearly it's not made for humans to work with. > It feels like you need too much built-in knowledge and understanding > of the pieces below you that do automagic to be able to use it well. > In essence, it feels a lot like how Debian packaging tooling feels to > me (in the bad ways). > > I try to avoid talking about this much, because historically I haven't > felt that my opinion would be valued there, but as a game developer of > an open source game, these kinds of things have held some degree of > interest for me. I considered making a Flatpak, and later taking over > the Flatpak in Flathub once one became available, but I absolutely > abhor the experience for developing and maintaining Flatpaks. As you > noted, the experience for developing Flatpaks is pretty bad. The > experience for Flathub indicates that nobody has seriously thought > about how a developer experience for producing and submitting Flatpaks > should work. I mean, really? Submitting GitHub PRs to a "null repo" > and then manually going through crap to transfer that into an > individual repo, then closing the PR? That's seriously speaking to > lack of interest in making a coherent and streamlined developer > experience. > > Now all of these problems are only unique to the GNOME implementation > of Flatpak. Fedora's implementation of Flatpak works a bit > differently, leveraging the Modularity technology to get things > working. With the Fedora implementation, there's still a few problems: > * Everything *still* has to get built over and over, which is frankly > quite dumb and wasteful, especially since we *know* what version of > Fedora everything is built for. Reuse would be a major accelerator of > adoption. > * It is somewhat unclear how the build orchestration works. I know > that a modulemd.yaml is involved and some kind of container build > definition, but not much else. > * The Flatpak naming restriction makes things get really ugly since > you need to force to fit RDNN naming convention. > > The submission experience for new flatpaks is essentially the same as > RPMs. So while not good, it's not entirely awful like the Flathub one > is. Maybe one day that will be improved for RPMs, containers, modules, > and Flatpaks... > > You may find that Fedora Flatpaks will be a better way to get your app > built. > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- LinkedIn <https://www.linkedin.com/in/blaisepabon/> | Quora <https://www.quora.com/profile/Blaise-Pabon> | Github <https://github.com/blaisep> “If you want to go fast, go alone. If you want to go far, go together.” --African proverb
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
