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 <ngompa13@xxxxxxxxx> wrote:
On Mon, Apr 13, 2020 at 6:53 PM Richard Shaw <hobbes1069@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
