[ANNOUNCE] D-Bus 1.0 RC 2 (0.94) released

David Zeuthen david at fubar.dk
Tue Oct 17 10:04:32 PDT 2006

On Sun, 2006-10-15 at 14:18 -0400, Havoc Pennington wrote:
> IMO the uuid should potentially be at an even lower level, it's almost a 
> kernel or init feature except we need it cross-platform. It's something 
> we've wanted lots of times over the years.

So, I think the key here is that what you need in D-Bus isn't really


but just


to solve your problem. Because that's really all you need for D-Bus to
work with remote X.

Deciding to solve the harder problem of providing GetMachineUUID() has
several implications because people will expect it to be stable across
reboots as they might use it as a reference in various places. It's just
bound to happen.

(and I don't really care about what number of disclaimers the docs for
GetMachineUUID() contains such as "it's not stable across reboots". The
name clearly is "Get the Machine Unique Identifier", why would that ever
change across reboot? If it does change across reboot (and the machine
is the same) we need to rename that function to the bloody long function
name GetUUIDThatIsStableForLifetimeOfOSSession() or something more
descriptive that isn't a lie.)

(and I do agree that it would be nice with GetMachineUUID() and I
appreciate that effort... but realize it's just a bit harder. At least
it requires better guidelines from D-Bus developers to distributors)

> If you want to fix stateless/OLPC/livecd removing the %post has nothing 
> to do with it; they aren't going to run the %post anyway. 

Sure it does. The %post runs on stateless/OLPC/livecd compose time (it's
a chroot install, basically) so either

 - the initscript generates a new UUID on every reboot
   => BAD; I think we want GetMachineUUID() to return the same UUID
      on the same machine even across reboots. Of course this requires
      some persistent storage on the OS but e.g. OLPC got that

 - the initscript only generate a new UUID if there is nothing already
   => BAD; so the stateless/OLPC/livecd build processes need special
      knowledge that it needs to delete the UUID file

Hence, the sane recommendation is to ask distros to run it _only_ in the
initscript and never in %post. This way things won't break unexpected if
you decide to do a livecd etc. and is not a domain expert on D-Bus.
Which, you know, is the norm.

So I think all we need is to just recommend 

 - generate the UUID early on boot before anything initializes libdbus
   if the UUID file is not already there

 - never generate the UUID in %post

That's what I like the D-Bus docs / release notes / installation
instructions to say. 

I'm being a dick about this because I think it's obviously the wrong
recommendation to generate it in %post and why I started complaining in
the first place because that's what the release announcement said.


More information about the dbus mailing list