Proposed F19 Feature: Fedora Upgrade - using yum

[Simo Sorce]

On Fri, 2013-01-25 at 04:46 +0100, Lennart Poettering wrote:
> On Thu, 24.01.13 21:15, Simo Sorce (simo at redhat.com) wrote:
> 
> > On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
> > > I mean, here's an example: let's say openssl is updated, which is
> > > pulled
> > > in by a ton of other things, for example the libc NSS LDAP module. The
> > > libc NSS is used by at least half of all processes running on your
> > > system,
> > > and they all dlopen() the NSS module. So how do you now figure out
> > > which
> > > ones that are and how do you then figure out what the heck you need to
> > > do to get them restarted?
> > > 
> > A) there is no 'libc NSS LDAP module', nss_ldap is not part of libc and
> > is also deprecated on its own in favor of nss_ldapd and others.
> 
> Not part of libc? uh? no, of course not. It's still a module that is
> loaded into libc via the libc NSS scheme, which is the point I am making
> here...
> 
> And anyway you are missing the point here... this is just an
> example. It's not particularly hard to come up with a different
> example. Just think of some other NSS module, that uses some
> library. Because of NSS its's loaded into half of our processes, all
> they have to do is invoke gethostbyname() and the module and all
> depending libaries are mapped in, and how would ever detect that?

cat /proc/$pid/maps

> > B) Luckily we solved this case with SSSD, and this is exactly one of the
> > use cases we wanted to solve with it. The sssd client side that gets
> > loaded in processes has been made extremely simple and the protocol
> > fixed in stone exactly so that you can upgrade SSSD and it's
> > dependencies and even change sssd's configuration w/o having to restart
> > applications.
> 
> Well you "fixed" a tiny facet of the issue. As it turns out however sssd
> is not the only service we ship, is not the only package we ship, it's
> not the only NSS module we ship, and update nss_sssd is still not
> possible either...

And it is not necessary either, as I already explained.

> > So I would remove the nsswitch problem, for the most part (we still have
> > some nsswitch things sssd does not handle like hostname resolution, but
> > we may take that over as well if really necessary.
> 
> Dude, sssd is not the only NSS module in the world, and NSS not the only
> interface that uses dlopen(). Look at PAM, at gstreamer loading codecs,
> at iconv loading char maps, gtk loading gtk modules, pulseaudio loading
> pa modules, python loading any module, apache loading a module, gvfs
> loading gvfs modules, ppp loading some module, ...

Dude, nothing is perfect.

> There's no way to determine those deps from the outside.

Of course there is, for the currently running process.

But that is besides the point. yum upgrades, just like apt-get upgrades
work just fine in the very vast majority of times.

For daemons sensible rpms include condrestart statements.

If some user app misbehaves after the upgrade you just restart it. If
you know in advance which ones you *might* want to restart I will be
very glad if you give me a list as part of the final yum output, and I
will decide if I want to do that or not.

We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.

That said I think trying a distro-sync from a graphical session is just
a funny and instructive experience, I wouldn't recommend it as you'll
keep the pieces when your session blows up and brings with it your yum
upgrade, but it is certainly instructive :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York