My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the disruption
they always bring, at someone else's schedule. As you say, there are
good reasons why it's what it is now, and maybe you're right that it
can't be significantly changed. I am just trying to think what COULD be
done, because such improvements would benefit regular updates ('yum
update') as well.
On 01/25/2013 01:27 PM, Lennart Poettering wrote:
There is no sane way to determine all these dependencies, because many
of them are never explicit, and only temporary in nature. Well written
apps load a lot of resources lazily. That has the side effect that you
can never know those deps, until they are actually needed.
You are right, can't be solved with the simplistic approach I
discussed--it would have to be more complex than that. This of course
is true of any upgrade, even the routine 'yum update', so improving this
situation is desirable even if one disagrees about distribution upgrades.
We know what resources we had and what we replaced them with. Perhaps we
could at least tag the running processes that will need restarting and
notify the users/administrators.
"kernel is hardest"? Yuck. Kernel is not feasible. And much of the rest
isn't either.
So kernel is out. DHCP is definitely possible. The others are somewhere
in between. My point again is that I think the upgrades are a sore point
for the users and it'd be nice to improve the process. If indeed this
can't be done properly, then the second best is a fall-back of having
the infrastructure to do it anyway and notify the user about which
pieces need special attention.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
