storaged: why did we fork udisks2

[Bastien Nocera]

On Thu, 2015-11-19 at 10:30 +0100, Tomáš Smetana wrote:
> On Wed, 18 Nov 2015 17:40:33 +0100
> Bastien Nocera <hadess at hadess.net> wrote:
> 
> > On Wed, 2015-11-11 at 11:27 +0100, Tomáš Smetana wrote:
> > > Hello.
> > > 
> > 
> > > If udisks2 upstream would be willing to support the server-type use
> > > cases, we would of course gladly join them. But again: it's already many
> > > years old topic. And unless udisks2 upstream changes their mind, there is
> > > no other option than to continue with storaged.
> > 
> > This still doesn't explain why you changed the API, instead of
> > extending UDisks' one.
> 
> Because we were focused on the new projects and didn't want to pretend we're
> udisks2.  Also it's still not clear whether all the things we might want to
> do in the future would be possible just with udisks2 extension.  We may
> eventually want to diverge even in the parts that are common now.
>
> That, combined with the gratuitous renaming of all the sources files
> > means that 1) storaged isn't a drop-in replacement for udisks 2) it's
> > hard to share fixes between the 2 versions.
> 
> That's true. But again: being a drop-in replacement was not the main concern
> when we started and having to maintain compatibility with udisks2 seemed like
> additional burden.  Yes, it might make porting more difficult, however... How
> many projects actually depend on udisks2 and how deeply?

Enough core ones that you wouldn't be able to install both udisks2 and
storaged on the same system without running into serious problems.

Eg. you couldn't have Cockpit with storaged and GNOME with the gvfs
udisks2 backend or gnome-disk-utility installed on the same system
without them getting in each other's way.