On Fri, Apr 15, 2016 at 10:14 AM, Bastien Nocera <bnoc...@redhat.com> wrote: > > > ----- Original Message ----- >> On Fri, 15 Apr 2016 05:09:00 -0400 (EDT) >> Bastien Nocera <bnoc...@redhat.com> wrote: >> >> > Hey, >> ... >> > What are the additional dependencies compared to Udisks2? >> >> None AFAIK: storaged itself should not pull anything else than udisks2 in >> the current Rawhide. >> >> > Would gnome-disk-utility, gvfs, etc. work as well as they used to without >> > regressions when dropping in storaged, either on a running system, or when >> > compiling against it? >> >> Yes, such is the plan. >> >> > Will bug fixes and enhancements to the common part between storaged and >> > udisks2 be backported to udisks2? >> >> I assume this is a question for the udisks2 developers. > > It's not. I don't think that Workstation wants to stray from upstream GNOME, > which uses udisks2, so providing maintenance would be useful.
What about GNOME transitioning to use storaged directly? There are things missing for some time, like filesystem resize, LVM thin, almost anything related to Btrfs, etc. > >> > I'm fairly certain we don't want iSCSI binaries in the Workstation >> > installation (we've been trying to get rid of the ones that Anaconda brings >> > in already). >> > >> > I also don't see why ZRam is something 1) you'd want to have to configure, >> > 2) that has its place in a storage API. >> >> It's been put to the API because Blivet would like to use it from storaged >> eventually. > > Still, I don't understand the use-case for such an interface. It's the creation of a block device that needs configuration: size, max size, compression algorithm, and that config presumably needs to be stored somewhere to create zram and swap at boot since it's volatile. And since it's a alternative for swap on disk, it makes sense to have an API that the installer can use, and other things can modify/manage post-install rather than each thing having to reinvent that wheel. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
