Forum › Forums › Kafeneio Chats › In a Greek kafeneio › appimage vs flatpak vs snapcraft (exploring packaging alternatives)
- This topic has 4 replies, 2 voices, and was last updated Dec 6-12:42 am by Anonymous.
-
AuthorPosts
-
December 5, 2017 at 7:50 pm #3432
Anonymous
why explore alternatives:
1) FOSS projects are (thankfully) progressing at rapid pace. Increasingly noticeable, older software versions provided via debian repo packages are undesirable.
2) iso-bundled “pre-installed” applications (e.g. LibreOffice suite) hamper our ability to utilize the live-session toram boot option.
Instead, a self-contained LibreOffice appimage|flatpak could reside in /dev/*/LiveStorage, loaded on-demand if/when it is needed.(my collected notes also contain “reasons 3 & 4” ~~ not posting those until I can figure out how to convey ’em without using cusswords)
snapcraft notes:
snapcraft, aka Ubuntu Snaps, aka snappy: is a non-starter (framework is a blob, requires systemd)flatpak notes:
I had tested w/ antiX16 (not installable, due to systemd dependency).
Recently I read “no, flatpak is not systemd-dependent. If the debian package maintainer is doing that, it’s a BUG and should be reported“.
Okay, so I recently retested (antiX17 livesession + debian stable repositories).
The overhead from adding package “flatpak”, plus 2 dependent libraries, was only 3Mb….
but wow (!) for the “gbrainy” games package I had semi-randomly chosen as a test item, instead of 30Mb (debian “gbrainy” package, plus gobs of dependent packages), the flatpak installation would have added 120Mb !^—- would have: ultimately, installation failed. I’ll update this post with the exact errmsg (+screenshots) when I have my notes in hand.
The flatpak installer wanted to (needed to) set extended attributes, which is apparently unsupported in antix17 liveboot session.
Per kernel.org docs: “as of 2014, xattr support is automatic/implicit for ext4 filesystem “.
Per antiX kernel config, ext3 xattr support is enabled.
Per antiX live init, user_xattr arg is absent from all mount commands.
Reputedly (or, my takeaway from scouring docs) tmpfs does support extended attributes, but…
(requires CONFIG_TMPFS_XATTR in kernel config, and) does NOT support user.* attribute namespace. Result: getfattr —} “operation not supported”
December 5, 2017 at 8:18 pm #3433Anonymous
::https://github.com/AppImage/appimage.github.io
^—-v
https://appimage.github.io/
^—-v
https://appimage.github.io/apps/ (list has not been kept up-to-date “we currently have 159 apps in our database.”)https://appimage.org/
^—-v
https://github.com/AppImage/AppImageKit/wiki
^—-v
https://github.com/AppImage/AppImageKit/wiki/AppImages (lists 460 or so packaged software titles)
(This list is no longer maintained. Please head to the AppImageHub central directory of AppImages available instead.)
^—-v
https://appimage.github.io/apps/ ( runs ya in a circle, back to the “we currently have 159 apps in our database.” page )not easily found in the blather of all the above:
https://bintray.com/probono/AppImages
21pages of app listings @ 8 items per page ~= 169
sort by date:
— during Dec 2017, ONE (wireshark) has been added/updated
— during Nov 2017, FIVE packages were added or were updatedlet’s click and read the “listing catalog” page for the first-listed software title, Arduino.
https://bintray.com/probono/AppImages/Arduino
^——- no “meaningful” description provided, no link to the project’s site is provided, no screenshot(s) provided================
================
================https://flatpak.org
^—-v
https://flatpak.org/apps
^—-v
https://flathub.org/apps.html (approx 150 software titles listed)
^——- no “meaningful” description provided, no link to the project’s site is provided, no screenshot(s) provided
(many, mebbe even more than half listed here, are “electron” -based, bloaty bundles of goodness. Bleh!)================
================
================https://www.linux-apps.com/
^———- a site under the “freedesktop.org” umbrella
flatpakked software released are often announced here============
============
============(noted) currently available as appImage, and not as flatpak AFAICT:
waterfox(noted) currently available as flatpak, and not available as appImage AFAICT:
discord, azpainter, iridium, firefox, signal, runescape, pitivi, openarena, gbrainyDecember 5, 2017 at 8:22 pm #3434Member
cpoakes
::I note that Nitrux, an Ubuntu-based distro has abandoned working with snaps because code for snap servers is not publicly available. From Distrowatch News Issue 740:
…As we [Nitrux devs] continued to update the software center we came across another problem: We couldn’t create a Snap store of our own. What does that mean? It means that the only official way to get a Snap is through the Ubuntu Store (read: repository). Say we wanted to create our own platform to serve Snaps, well we can’t because the server-side software needed to do that is not publicly available to use by third parties (like us). In the future, NX Software Centre will be adjusted to work with AppImage portable packages in place of Snaps.
Seems to me if Ubuntu doesn’t open source this code immediately, snaps are dead in the water as a generic solution.
- This reply was modified 5 years, 5 months ago by cpoakes.
- This reply was modified 5 years, 5 months ago by cpoakes.
December 6, 2017 at 12:11 am #3448Anonymous
::Canonical’s back-end, regardless whether proprietary or not, is not a “deliverable”.
Said differently: its mechanizations are beyond the scope of the snapcraft project.At face value, in the eyes of the targeted audience, the NixOS newsbyte sounds “reasonable” but c’mon…
the NixOS devs just (now, suddenly) realized that should-have-been-obvious detail, regarding the back-end? D’oh!
To me, the newsbyte just represents an attempt to gain mindshare (NixOS brand recognition) by finding an excuse to kick Canonical in the groin.(analagous to “reproducible builds”)
Of course, by design, snaps blessed for use within the Snapcraft ecosystem must be built on Canonical’s back-end, using their signing keys.
BYOB ~~ free to build an alternate ecosystem, but ya gotta build yer own back-end.December 6, 2017 at 12:42 am #3449Anonymous
::if Ubuntu doesn’t open source this code immediately, snaps are dead in the water as a generic solution.
The NixOS gerrymandering newsbyte is moot.
Reiterating my point from post #1 (snapcraft is, already, D.O.A.)
snapcraft, aka Ubuntu Snaps, aka snappy: is a non-starter — its framework requires systemd
Hearts-n-Minds, baby!
“They” (NixOS, plus controlled media) are effectively bamboozling the audience, by proffering the notion that systemd is “a given” -
AuthorPosts
- You must be logged in to reply to this topic.