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

[Havoc Pennington]

David Zeuthen wrote:
> So, I think the key here is that what you need in D-Bus isn't really
> 
>  GetMachineUUID()
> 
> but just
> 
>  GetUUIDThatIsStableForLifetimeOfOSSession()
> 
> to solve your problem. Because that's really all you need for D-Bus to
> work with remote X.

It needs to be stable between reboots. If an app is sanely part of a 
session then this autolaunch stuff never comes into play. The magic bus 
discovery that uses the machine id only happens when you are running 
apps in some way outside the normal session (remote machine, different 
user, you're using twm and don't have a session bus in your login 
scripts, whatever)

Also, the GetMachineId call is intended in part to allow you to check 
whether a remote process is on your same machine.

I think keeping it the same across reboots would make it more useful, 
but dbus does not require that stronger guarantee.

> 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.

If we always regenerate it on reboot by defaulting to /var, then while 
people might get this wrong at first they'll fix it quickly, since the 
bug will happen reliably and for lots of users.

>> 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

stateless/livecd just requires special handling. It isn't hard, and 
those setups already require all sorts of special handling. I don't know 
exactly what the special handling is, so dbus is flexible about it. But 
I also don't see how dbus upstream can provide a default that works with 
both these setups and regular package-managed systems.

The chroot install for these is not per-machine. You don't do the chroot 
install for every system. That's what I mean when I say the %post is not 
going to run on each machine.

> 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.

If we move to /var by default then things will just work with a livecd.

>  - never generate the UUID in %post

If we move to /var by default then all this does is break things unless 
you reboot. What else does it do?

> 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.

Well, I think it's obviously wrong to have a busted system until I 
reboot. Assuming we move to /var by default, tell me what the %post will 
harm.

Havoc