35
Chrome/Chromium Experimenting With Flatpak Packaging (www.phoronix.com)
submitted 6 days ago* by to c/linux@lemmy.ml
9 comments fedilink hide all child comments
 

An exciting development for this Linux app sandboxing and distribution tech. This would also help improve Google Chrome/Chromium support outside the likes of RPM and Debian based distributions with a cleaner packaging experience.

That's what he said.

all 9 comments

sorted by: hot top controversial new old
[–] 11 points 6 days ago (2 children)

I’ve been using the Flatpak version of Ungoogled Chromium for a while now (for websites that don’t work natively with Librewolf). Is this really that new?

  • permalink
  • fedilink
  • source
  • hideshow 4 child comments
    •
  • [–] 1 point 5 days ago

    The main Chrome flatpak currently just installs the official RPM file for Chrome. You're right that the Chromium and Ungoogled Chromium ones do seem to build from source a bit more. I imagine it will just mean a better build process with less patching.

    But you can see exactly what it means right in the ticket:

    • Create chrome/installer/linux/flatpak/ with packaging scripts and templates for metadata, AppStream metainfo, and launcher entrypoint.
    • Add enable_flatpak GN build argument (default false).
    • Add package_format to InstallerConfig and omit host desktop integration artifacts (system desktop files, /usr/bin symlinks, AppStream appdata, GNOME default apps, manpages, and AppArmor profiles) when packaging for Flatpak.
    • Update common/installer.py with Flatpak configuration and App ID mapping for Chromium (org.chromium.Chromium*) and Google Chrome (com.google.Chrome*).
    • Generalize common/desktop.template to support both Flatpak and system-wide desktop execution commands.
    • Disable setuid sandbox and zlib compression for non-official builds.
    • Update BUILD.gn with flatpak packaging targets and aliases.
  • permalink
  • fedilink
  • source
  • parent
    • [–] 8 points 5 days ago (1 child)

    I'd be more impressed if they stopped bundling random crap. It's their unwillingness to use upstream's dependencies and toolchains that makes Chromium a nightmare to package on Gentoo, and flatpaks are not going to fix that. They bundle clang, rust, and so many additional libraries that the "must keep bundled version to prevent breakage" list is almost 300 items long. This is not the correct way to ensure reproducibility, guys.

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 2 points 5 days ago

    chromium seems to serve as a basis for google dominance in the browser space so it makes sense that they would intentionally fuck with it in a way that doesn't let others have full control.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 2 points 5 days ago (1 child)

    I thought that Flatpak breaks unprivileged user namespaces

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
  • [–] 2 points 5 days ago (1 child)

    Flatpak does block userns. Apps on Android don't get unprivileged user namespaces, and Chromium is at its strongest on Android. So I have to assume there is some way of making it secure inside an app sandbox.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • [–] 0 points 6 days ago

    Thankfully Librewolf still uses AppImage as an option.

    The only Flatpak I bother with is the Kodi one because my distro has incompatible (read stable) library version on several things for compiling it and I'm considering just jumping to jellyfin for that, as well.

  • permalink
  • fedilink
  • source
    •