On Fri, 2017-06-23 at 15:56 -0400, Colin Walters wrote:
On Fri, Jun 23, 2017, at 03:38 PM, Adam Williamson wrote:
Well, yes, but I'm usually talking from the *user* perspective. So far as the user is concerned, it's not an RPM-based system: we can't test updates by fiddling around with dnf, is the pertinent point here.
But one can (and is definitely expected to in many general cases) to use layered packages. A lot (but not all) of the functionality of dnf is also possible with rpm-ostree - increasingly so, for example we're working on supporting "removing" things from the base tree: https://github.com/projectatomic/rpm-ostree/pull/797
Ah, I see, thanks for the clarification; so, long story short, we *could* actually test using dnf for install / remove / update of packages on Workstation-ostree? But is this also something that's already tested in CentOS CI? If so, probably not worth duplicating it.
If we have another system where we can test the update experience exactly as it works for a real end user - starting from deploying ostree Workstation in the way we actually expect a user to do so, starting from our actual nightly / candidate images - then that's great, let's do that. But if we don't, openQA is probably a practical way to do it. What I'm really kinda looking for is more specific details on the level of "here is approximately what you could do to reliably put a Workstation ostree system into a state where an update for it would be available through the usual mechanism".
We already indeed do these types of things in CentOS CI.
Great, one less thing for me to worry about, then. Well. I suppose there's one more thing to ask: do you test install from the *installer image* in CentOS CI? If not, how significant are the chances (do you think) that a system installed from the installer image might differ in its behaviour from one deployed via a filesystem image or however you get to the starting state of the CentOS CI tests?
Still, thinking about it, for ostree Workstation we really need to test two *separate* things, yes? Updating the base system, and then deploying and updating software on top of the base system.
Right!
Again, more details on how that process is expected to work would be useful; are Flatpaks the only expected deployment method for apps on ostree Workstation, for instance?
No. There's lots of stuff that isn't yet in flatpak form. And further, not everything is a desktop app.
OK, so, to summarize, you expect people to deploy stuff on top of ostree Workstation:
* Via layered packages (which is basically just 'dnf install foo' so far as the end user is concerned, right?)
* As Flatpaks, installed via GNOME Software
* As containers
Does that sound about right? Thanks!