setup flathub repo by default
Closed, ResolvedPublic

Description

flathub is more or less the go-to provider for flatpak repos, we should set it up by default. this would allow users to install flatpaks in discover without having to first set up the repo

sitter created this task.Sep 24 2018, 10:55 AM
sitter triaged this task as Normal priority.

Do this in post install discover so Flatpaks are ready to install
https://flatpak.org/setup/Ubuntu/

jriddell moved this task from Later to Backlog on the KDE Neon : bionic board.Oct 3 2018, 8:35 AM
sitter moved this task from Backlog to Doing on the KDE Neon : bionic board.Oct 10 2018, 1:09 PM

Can't QA because our branches are inconsistent crap still.

T9836 -> T9834 -> T9835

This is working now when updating

BUT!

This has a flaw with offline updates. Offline updates won't have network access and thus the remote adding will fail. This possibly should be turned into a systemd service that runs on startup (once) and depends on network.target.

Also ISO still needs verification.

yeah, so, I think I'll convert this to a systemd service. possibly have the service disable itself so it doesn't needlessly get looked at after it ran once. also, that way the service won't add the repo back if the user manually removed it for whatever reason (i.e. we have a record of if we added it automatically or not - the disabledness)

Service is still not too exiting because the user may not be online right away (wifi or whatever). Perhaps service + regular timer? Alternatively we could maybe write a PreStart script which blocks until internet access is available? The former is probably easier while the latter may be nicer as we could wait on a dbus signal. I am somewhat undecided here :S

Eh eh, the latter is probably easier. In that we don't have to wait for a signal we could just poll in a loop in a shell script. And since it is PreStart the service will never enter running state if the poll never succeeds. With the former one would do the same albeit through a systemd timer which means playing around with those for very little gain I'd imagine.

ngraham added a subscriber: ngraham.Nov 4 2018, 4:30 PM

This has moved to neon-settings and is now using a systemd service.

Two things I still do not like about the implementation:

  • because the service is singleshot it blocks indefinitely (or until flathub gets added) which means dh_systemd starting it on installation also blocks. it's a problem which conceivably is only solvable by making the service non-singleshot I guess
  • it will attempt adding flathub on a 30 minute timer, but that seems super long for the first bunch of failures. it's not unreasonable to assume that the service runs before network is connected to the internet, so the first call would almost always fail. it may make sense to make the sleep increment from 1 minute to 5 to 15 to 30? that's gonna be horrible to implement in bash I fear :S
sitter closed this task as Resolved.Feb 11 2019, 3:49 PM
sitter claimed this task.

Exploded shortly after landed in user edition by somehow managing to block sddm for some users and in a probably related matter blocked systemd-analyze from analyzing because it considered the unit part of the startup chain. I had to make the impl changes from the previous comment to resolve that. It's now written in a sane language, increments the sleep time, and no longer systemd singleshot. No further issues.
Bhushan and Aleix also talked to upstream about actually fixing the system to "preseed" remotes via /etc, so perhaps come 20.04 we'll not need this crappy workaround anymore.