<walters> otaylor, https://pagure.io/workstation-ostree-config/pull-request/29
<mclasen> can we decouple the questions  of what should be in the image and what should be installed by default ? ie could we remove cheese from the image, and still install it by default (as a flatpak) ?
<mclasen> most of these are uncontroversial, I think
<walters> we clearly should be able to bake in flatpaks by default, it might not be hard to do but it's not entirely straightforward either
<walters> one problem it instantly raises is: flatpaks from where?
<mclasen> I would think all except for the desktop apps are fine to just push
<mclasen> right
<walters> so you're saying rebase without the desktop apps patch for now?
<walters> not opposed to that...we are going to have some issues until gnome-software learns to speak to rpm-ostree for package layering instead of PK
<mclasen> yeah
<mclasen> kalev-afk: how's that looking ? (g-s speaking rpm-ostreed)
<otaylor> walters: I think the ostree image needs to have the same apps as the default workstation install until we have some way of doing flatpaks-by-default
<otaylor> walters: does abrt not work with rpm-ostree or is it removed in your pr because you feel it's (generally) not useful?
<walters> otaylor, one thing that we will have to reconcile is the "same workstation, just rpm-ostree" versus "atomicws"
<walters> a major subpoint of that being "no devel tools on host"
<otaylor> We don't really have devel tools in the dfeault workstation install
<otaylor> I dont' expect the workstation we ship to be the *only* possible workstation ostree - it should be something that is comfortable to use out of the box without having to install a bunch of flatpaks or layer
<otaylor> That means that it's going to have some things which are don't seem like "core"
<walters> hmm, i thought there were but it does look like in comps `developer-workstation-environment` is indeed separate
<walters> i guess my perspective is; we're not going to have something that feels polished out of the box in the short term
<otaylor> For the developer side, definitely
<walters> i'm more concerned about keeping the groundwork going and fixing basic bugs
<otaylor> For a user, I don't really see why not
<otaylor> (depending what you mean  by short-term)
<walters> f26 = short term
<otaylor> walters: the lack of flatpaks definitely means that f26 it's not going to be polished out of the box
<walters> well...AFAIK every desktop app should be `rpm-ostree install` able
<otaylor> (also the lack of gnome-software rpm-ostree integration)
<walters> yeah *that* is going to be a major polish hit
<walters> but on the other hand, the default host upgrade command won't delete all the files underneath your running apps and break them
<walters> on abrt...i was more sync'ing with what's in atomic-ws
<walters> basically with the concept of keeping the host small by default
<walters> abrt does a lot of things and clearly crash telemetry is very valuable
<walters> so...i'm ok keeping it
<walters> i'll redo the pr with apps and abrt retained then
<otaylor> walters: I would also argue that separately maintaining the set of command line utilities here as compared to the workstation default install is not something I want to do - if wvdial is no longer useful, I don't want to decide that *separately* for the ostree configuration
<otaylor> I suppose the argument really is that we shouldn't be maintaining comps and the live image ks and this file separately to begin with...
<walters> i.e. https://github.com/projectatomic/rpm-ostree/issues/744 ?
<walters> yes...but i dunno
<walters> i guess my perspective here is any work curating in comps is mostly meaningless
<walters> since once you've installed and installed/removed things and upgraded for a few releases, the whole system has degraded into a big bag of packages
<walters> whether you have telnet or not...who knows
<otaylor> well, but if we can repurpose that work as the work of curating the ostree image, then suddenly you can no longer say that
<walters> yes
<otaylor> And we don't have some meaningless task that we still have to keep on doing until we abandon traditional installs
<otaylor> Also, if the comps and the rpm-ostree aren't in sync, the build breaks
<otaylor> See my attempt to backport the atomic+docker additions from rawhide to f26...
<walters> hm, there actually is a lot more activity in comps than i thought there'd be
<walters> for workstation
<walters> hm?  I think the main thing that actually failed composes was the explicitly specified library deps
<otaylor> I can't say what the main thing is - but because the workstation ostree is composed against the workstation yum repository, if you try to add something to the rpm-ostree config that isn't in workstation comps, it breaks
<otaylor> https://kojipkgs.fedoraproject.org/compose/branched/Fedora-26-20170518.n.0/logs/x86_64/ostree/ostree-3/create-ostree-repo.log
<walters> oh, that
<walters> yeah that's going to be problematic
<walters> oh i see, workstation-ostree-support
<walters> wow
<walters> https://pagure.io/workstation-ostree-config/issue/26#comment-440880