Re: F39 Change Proposal: Flatpaks without Modules (System-Wide Change)

Owen Taylor <otaylor@xxxxxxxxxx> · Sat, 13 May 2023 14:24:59 -0400

On Sat, May 13, 2023, 4:24 AM Mattia Verga via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

    Il 13/05/23 03:04, Owen Tay rt I look 

              On Fri, May 12, 2023,
                1:03 PM Mattia Verga via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx>
                wrote:

              Il
                10/05/23 12:54, Aoife Moloney ha scritto:
M kk kk kk kk o kk kk kk I I'll k> https://fedoraproject.org/wiki/Changes/FlatpaksWithoutModules

                >

                >

                I've never tried to make a flatpak because I was scared
                by the need of 

                firstly build modules and I'm really happy to see this
                change moving on.

                However, there's something I can't understand: AFAIK, a
                flatpak is 

                platform independent, so a flatpak built on F39 can be
                installed on any 

                Fedora version or even on other Linux distributions...
                right?

                So, why having all those "Fedora Containers" releases in
                Bodhi which 

                follow Fedora branches? Isn't just one Fedora Containers
                release enough? 

                What happens if one builds the same flatpak on multiple
                Fedora 

                Containers releases?

                infrastructure/new_issue

          The "F38 Flatpaks" release in Bodhi represents
            Flatpaks built with the F38 package set against the F8
            runtime. But, yes, as you say we handle Flatpaks as a single
            stream. Once we release Firefox into "F39 Flatpaks",
            everybody on all releases gets that and we never do an
            update in "F38 Flatpaks" again.

          If updates *do* get pushed on multiple
            releases, last pushed wins. Might be useful if we found that
            we pushed something to early or broken - but isn't normal.

    I was wondering if that was due to have the ability of building
      the flatpak against a specific runtime. I mean, as I understand
      how a flatpak works, a flatpak created from a koji build for f39
      will be built against a specific runtime (say, KDE available in
      f39 stable tags), but when we build the same koji build for f40 we
      will be using a different runtime which may not be compatible...
      so still having a Fedora Containers 39 release will make the
      maintainer able to continue using the f39 runtime... I know I'm
      quite confused, aren't I?
    If I search for fedora-toolbox updates in Bodhi, I now see there
      are multiple updates released alongside each others at the same
      time
I think some of the confusion comes from the fact that fedora-toolbox is not a Flatpak at all and we have different bodhi releases and policies for Flatpaks and other containers. We naturally do want parallel versions of the toolbox container - you should be able to create a F37 Toolbox or a F38 Toolbox or ...

          But what if we had a single release instead?

          On a technical level, we rely on separate releases
            because Bodhi is using that to know what koji tag to pull
            from. So to merge them, we'd probably need a single dest tag
            in Koji as well. But would it be more convenient and less
            confusing for packagers and users? Would there be any
            performance or UI problems from having a release in Bodhi
            that extends indefinitely?

    Would be simpler to have a single Koji dest tag which doesn't
      change alongside Fedora branches, so that packagers only have to
      remember that one? (provided that we don't want the ability to
      build multiple updates as discussed above)
fedpkg automatically determined the target based on the runtime specified in container.yaml. We'd need separate targets in any case because the build tag where the packages installed in the container come from needs to be different based on the runtime version / fedora release. But the different targets could potentially share a single dest tag.

One thing that would need to change in this model would be the name of the runtime container in koji/bodhi. We'd probably need to have it be flatpak-runtime-f38 or something like that, or it would be confusing to be doing parallel updates into a single dest tag and bodhi release.

(The runtime needs security updates as long as we have any applications still using it.)

    From a Bodhi POV, I don't think there would be any problem in
      extending a release indefinitely... we currently have Fedora ELN
      running since 2020 and with something like 80K updates and nothing
      as blown up (yet...)
Well, that answers that question :-)

I've created: https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/15 to track this idea, and will bring it up in the next Fedora Flatpaks SIG meeting.

Owen

_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue