On Fri, Apr 15, 2016 at 10:14 AM, Bastien Nocera <bnocera(a)redhat.com> wrote:
----- Original Message -----
> On Fri, 15 Apr 2016 05:09:00 -0400 (EDT)
> Bastien Nocera <bnocera(a)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
> > 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
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