Thanks folks, Really convincing answers! 2016-04-28 13:53 GMT-03:00 Dennis Jacobfeuerborn <dennisml at conversis.de>: > On 28.04.2016 17:58, Lamar Owen wrote: > > On 04/28/2016 08:45 AM, Sergio Belkin wrote: > >> I've found some issues upgrading mysql, some people recommends run > >> mysql_upgrade. I wonder why such a script is not run from scriptlet of > >> mysql-server rpm. > > Back in the Dark Ages of the PostgreSQL RPMset (PostgreSQL 6.5), early > > in my time as RPM maintainer for the community PostgreSQL.org RPMset, I > > asked a very similar question of some folks, and I got a canonical > > answer from Mr. RPM himself, Jeff Johnson. > > > > The answer is not very complex, but it was spread across a several > > message private e-mail thread. The gist of it is that the RPM > > scriptlets are very very limited in what they can do. Trying to do > > something clever inside an RPM scriptlet is almost never wise. The key > > thing to remember is that the scriptlet has to be able to be run during > > the OS install phase (back when upgrades were actually supported by the > > OS installer that is now known as anaconda). Quoting this introductory > > section: > > > > On August 18, 1999, Jeff Johnson wrote: > >> The Red Hat install environment is a chroot. That means no daemons, > >> no network, no devices, nothing. Even sniffing /proc can be problematic > >> in certain cases. > > > > Now, I realize that that is OLD information; however, anaconda is still > > doing the same basic chrooted install, just with a prettier face. You > > cannot start a daemon in the chroot, since many things are simply not > > available to the scriptlets when installed/upgraded by anaconda. > > Scriptlets have to work in an environment other than 'yum update.' And > > also note that this is a very different situation than Debian packages > > live in; RPM scriptlets are essentially forbidden from interactivity > > with the user; Debian's equivalent are not so hindered. At least that > > was the rule as long as I was an active packager. > > > > Further reference a WayBack Machine archive of a page I wrote long ago: > > > https://web.archive.org/web/20010122090200/http://www.ramifordistat.net/postgres/rpm_upgrade.html > > > > > > And leaving you with this thought, again from Jeff Johnson: > > > > On August 18, 1999, Jeff Johnson wrote: > >> Good. Now you're starting to think like a packager Avoiding MUD is > >> *much* more important than attempting magic. > > .... > > > >> The bottom line is you shouldn't attempt a database conversion as > >> part of the package install. The package, however, should contain > > programs > >> and procedures necessary to do the job. > > The real reason something like mysql_upgrade isn't run automatically > hasn't really much to do with the technicalities of RPM but the fact > that mysql_upgrade might kill your server if you don't know what you are > doing. > If for example you have a big table that takes up 70% of your storage > and mysql_upgrade needs to convert it to a new format then it will > create a copy of that table in the new format first and then delete the > old one...except of course that this would require 140% of disk space to > work. > > So independent of the packaging technology used major changes like these > should never be done automatically and instead always be handled by an > admin who knows what he is doing. > > Regards, > Dennis > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos > -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org