Re: [atomic-devel] please help us test atomic workstation/host images for f27

[William Brown <wibrown redhat com>]

On Mon, 2017-11-13 at 09:05 -0500, Colin Walters wrote:
> 
> On Sat, Nov 11, 2017, at 07:00 PM, William Brown wrote:
> > 
> > 1) opensc should be part of the base image as it enables freeipa
> > smartcard authentication and other related parts to work correctly
> > (I'm
> > layering it in for now 
> 
> Me too, in my case for yubikey.   That said my opinion here is that
> we simply cannot
> meet the conflicting goals of "small base" and "full functionality"
> without
> involving some package layering particularly for individual
> machines.  I think
> the package layering is what makes the system fully practical
> today.   I also
> have `vagrant-libvirt` and `origin-clients` layered, as well as a few
> random
> things like `xsel`, `powerline`, and `git-evtag`.
> 
> (On my home Atomic Host server I also have`libvirt` layered, which is
>  a big topic in itself)
> 
> That said I think it's really interesting to have this debate; the
> transition
> from "no layering" to "some layering" is a large one (suddenly e.g.
> you
> need to download the 40MB repodata just to check if you have an
> update).
> And rpm-ostree is very "loud" in the `status` command about exactly
> what you have layered - in large contrast to every other "package
> classification"
> in Fedora like comps, which tends to just dissolve into the "bag of
> packages"
> model.
> 
> I think we'll need to take some of this to the Workstation list -
> there's
> a lot of bigger picture questions around how much the default set
> resembles
> the default workstation.  For example, IMO we shouldn't include many
> apps
> at all by default, since it's confusing to have both a flatpak
> version and a built-in.
> But there are deep issues there - if we go to the point of not having
> a browser
> by default for example, that'll create bootstrapping issues for some
> people.
> 
> Personally though I think the most important thing is to make the
> "tools/dev"
> container flow more friendly.  That's something people can do without
> going all the way to Atomic Workstation.

If we were more commited to this we could have "atomic workstation" and
"atomic developer station"? Where we basically have the same .json and
add more tools to it IE libvirt? 

Like, is there a great cost to adding another ostree branch?

The risk is trying to satisfy "all needs" rather than general case
though .... 


> 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane