[GNC-dev] [MAINT] Cleaning up Code (the server)
Geert Janssens
geert.gnucash at kobaltwit.be
Thu Aug 22 04:29:57 EDT 2019
Op dinsdag 13 augustus 2019 22:53:34 CEST schreef John Ralls:
> > On Aug 13, 2019, at 9:14 AM, Derek Atkins <derek at ihtfp.com> wrote:
> >> There don't seem to be any flatpak release builds. Should there be and if
> >> so should I include them in the release downloads on SourceForge and
> >> Github?
> >
> > Not yet. Remember that right now code is sitting behind a tiny straw.
> > Once I can move back to my main network then we can advertise that.
>
> This wouldn't be advertising, it would be me downloading one flatpack at
> release and uploading it to SF and Github just as I do with Windows
> releases.
Flatpak by default works slightly differently: instead of distributing a
selfcontained installer it stores all builds in a public repo and that's where
users would expect to get it from. The most widely known and used repo is
currently flathub.org.
Also you don't upload a fully built package to flathub. Instead you commit the
build manifest and their buildsystem will use that to reproduce the necessary
build artefacts that allows users to install the newest gnucash package from
flathub.
I have recently become co-maintainer (well, defacto maintainer) of the gnucash
repo on flathub. I have been tweaking their build manifest file to be closer
to the one we use for our nightly builds.
My ultimate goal is to be able to simply push the manifest generated for our
release nightly build to flathub. The idea is that if our nightly build server
can successfully build the release, flathub will be able to as well. As they
use the same strictly defined sandboxes that should work most of the cases.
The only caveat: flathub builds for 4 architectures (arm, aarch64, i386,
x86_64), we build only for one. So if we have architecture incompatibilities,
things may break anyway. That would require manual tweaks of the manifest for
flathub. The typical handling of package failures (on distros as well) is
adding patches to fix the issue. These patches would probably also be applied
to our source repos so they'll become incorporated in the next release
tarball.
Regards,
Geert
More information about the gnucash-devel
mailing list