On 06/20/2012 06:59 PM, Reindl Harald wrote:
Am 20.06.2012 17:42, schrieb Panu Matilainen:
On 06/20/2012 03:37 PM, Reindl Harald wrote:
Am 20.06.2012 14:32, schrieb Björn Persson:
Michal Hlavinka wrote:
Correct approach would be to save state before installation of new
version starts and start dovecot (if flag is set) after old version is
removed - that would mean %postun script. This does not seem to work on
reinstall (the same version is installed) - %postun script is not executed.
Please also consider what happens when the new version of Dovecot requires a
new version of some library. RPM will ensure that both packages are updated in
the same transaction, but if I understand correctly it's not until %posttrans
that you can be sure that the new library is in place.
one reason more why the cuurent behavior re-starting services
on updates is simply wrong:
It's also not true.
If new dovecot requires new version of libfoo, that new libfoo with all its files
is guaranteed [*] to be installed before the new dovecot, ditto for all their
dependencies recursively. Reverse for the erasure phase, eg the older
libfoo version is only removed after everything depending on it has been removed.
boah and if it does NOT require a new version because it is
not a new version of a library since new releae-version
with patches is not uncommon and if one of the patches
is security relevant there is NO gurantee that the service
itslef would not be restarted BEFORE the pacth is applied
Rpm always orders by dependencies within a transaction, so if library
and the service depending on the library are updated in the same
transaction the library will be updated first.
If you think about it a little, not a single upgrade involving soname bumps and
the like would work properly if it wasn't like that
i do not need to think
i was there, i saw was happened on dist-upgrades, i fixed them
i saw a dist-upgrade on the fist-testmachine restart httpd
which failed for some reason and AFTER some time you could
start httpd again
* i rebuilt the httpd package
* i removed the dumb restart from the SPEC file
* i rolled out the dist-upgrade on 20 production machines
* no second downtime of httpd except the usual reboot
don't get me wrong, but i am not interested in theory
i am intersted in stable update-processes whch were painless
years ago and now can only be achievd be rebuilt a lot of pakcages
"Some reason" can't be analyzed... but like said, there certainly are
all sorts of gaps and holes where things can be temporarily broken while
a transaction is running, including file-renames, old files from
previous version still being around, dependencies (such as service
inter-dependencies) which rpm does not know about, dlopen()'ed libraries
etc. Most of the time things work well enough that nobody notices, but
an assumption that the system stays in a fully consistent state
throughout an online update is simply bogus, service restarts or not.
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
