On Tue, Jul 18, 2017 at 12:14 PM, Hedayat Vatankhah <hedayat....@gmail.com> wrote: > > /*Chris Murphy*/ wrote on Tue, 18 Jul 2017 09:28:53 -0600: >> >> On Tue, Jul 18, 2017 at 8:19 AM, Dominik 'Rathann' Mierzejewski >> <domi...@greysector.net> wrote: > > ... >>> >>> >>> "One size fits everyone" approach can be dangerous. It never does, in >>> fact, fit everyone, and often sacrifices flexibility and resource usage >>> for the convenience of a single image. >>> >>> I, for one, like to keep my installations minimal and I often uninstall >>> optional (weak) dependencies manually. With Atomic base I wouldn't >>> be able to modify the base easily on my system(s). >> >> It's a layered approach. rpm-ostree does let you unlock the base and >> install and remove RPMs. You could also run the server side component >> that turns RPMs into ostrees yourself (locally or in cloud) and have >> however many trees you want, and establish your own rebase policy for >> your workstations. > > But if I've understood correctly, any changes to the base will be discarded > when you update the base image. right?
I'm not sure what the long term plan is. Right now changes to /usr (normally read only) is done with overlayfs, with the backing directories in /var/tmp, and are intended to go away at next reboot. I think what we'll find with deduplication on the Fedora side, is there will be a bunch of streams for given products, and you can pick how big of a base you want. Right now there are a bunch of graphical applications in the base because they haven't been flatpak'd yet. What I'm reading is any graphical application will get flatpak'd so they are separate from the base, and each other. You can update all or you can update individually or not at all. -- Chris Murphy _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
