Schedule for Monday's FESCo Meeting (2012-06-18)
skvidal at fedoraproject.org
Mon Jun 18 14:32:44 UTC 2012
On Mon, 18 Jun 2012, Richard Hughes wrote:
> On 18 June 2012 00:38, Reindl Harald <h.reindl at thelounge.net> wrote:
>> the point is that it was perfectly possible in 2005 to make a fedora
>> dist-upgrade at friday night while http, netatalk or samba was
>> fully up and running until saturday sometimes at evening where
>> you rebootet the machine and now EIGHT years later we discuss about
>> making updates at reboot/offline like windows?
> Well, if you're running a headless server with just http, netatalk and
> samba then you can of course update now live using yum, restarting
> services when convenient. I'm not going to change that. What I want to
> change is for the case of updating a fully functioning desktop with
> ~30 session processes per user talking to each other over session
> DBus, ~20 doing IPC with system DBus, and ~15 processes in the system
> context, ~3 of which do DBus IPC with each other. That's about as far
> removed from a simple server with three non-connected daemons that do
> one thing each as you can get.
>> something must have gone terrible wrong in the meantime
> If your goal is to just run three simple daemons, I agree.
As dbus is required for various things like networkmanager - does this
mean that if a server happens to be using nm for network setup that in
order to apply a security patch to dbus, for example, that the server will require
Since more and more we're relying on dbus for server-y processes it feels
like we'll be adding one more component that requires a reboot for updates
to take effect. That eats up real time and causes real pain later on for
admins maintaining systems.
Either we need to make dbus something we can sensibly restart or we need
to rely on it less for server-y tasks (or both).
I understand you're not working on PK for servers but the packaging
expectations will trickle down to our slower-changing server installations
and this will cause real pain and irritation. The implications for servers
are fairly serious.
More information about the devel