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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
