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
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.
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.
I have `emacs flatpak-builder opensc pcsc-lite-ccid keepassx powerline tmux
vagrant-libvirt virt-manager ykclient`
layered here for example; about half of those are desktop apps I haven't
bothered to try to flatpak, and most of them are privileged anyways. Half are utilities
or userspace driver-type things like ykclient.
Now things like `fedpkg` live in my tools container.
I also have `oc cluster up` going for server side development.
There's a bit more here:
https://fedoraproject.org/wiki/Workstation/AtomicWorkstation
(Though origin-clients isn't yet in "workstation-ostree" partly due to this
ongoing
slow moving debate about whether it's "the same workstation, just with
rpm-ostree"
or whether it's something more different than that where e.g. devel tools are always
in a container, one uses openshift for local server development etc)