Thanks folks,
Really convincing answers!
2016-04-28 13:53 GMT-03:00 Dennis Jacobfeuerborn <dennisml@xxxxxxxxxxxx>:
> 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@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
--
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
