How to work around a error in an eclass file located in a Gentoo overlay?

Question

   (cross-posting from the Gentoo forum)

I try editing the .eclass file in order to correct the error, but it seems my edits are being defeated by a cache somewhere. The initial error occurs when I run the command emerge --config =dev-db/mysql-5.7.12, which I must do in order to finish installing my build of MySQL. The command fails and /var/log/mysql/mysqld.err says:

[ERROR] Too many arguments (first extra is
  ''--init-file=/var/tmp/portage/dev-db/mysql-5.7.12/temp/tmp.COaXRiJpf9'').

I traced it to a file named mysql-multilib-r1.eclass. I found two versions of this file on my system; one in the main Gentoo repository (priority -1000) under /usr/portage/eclass/, and the other in the overlay repository (+50). The overlay repository is maintained by Layman and the name of the overlay is ‘mysql’. — I’m using it to gain access to MySQL 5.7, which hasn’t arrived in the main repository yet. — Specifically I traced the error to line 953 in the overlay version of the file, or 945 in the main version:

initialize_options="--initialize-insecure  '--init-file=${sqltmp}'"

Probably the single quotes are causing the --init-file option to be interpreted as a proper argument. I just need to remove them. But when I do, it has no effect. My edits to this file — no matter which version I edit — are ignored. I’ve been careful to delete the contents of /var/tmp/portage in case it’s caching there. I also tried synchronizing the repositories:

layman --sync ALL
emerge --sync

I tried synchronizing them before editing the two versions of the file, and also after editing — in this case clobbering my edits to the main version but (oddly) not the overlay version. Neither helped.

The Gentoo developer manual suggests that I might need to ‘manually touch all relevant overlay files after updating overlay eclasses’. I tried doing that, too; touching all files under these directories:

/usr/portage/dev-db
/usr/portage/eclass
/usr/portage/virtual/mysql
/var/lib/layman/mysql/dev-db
/var/lib/layman/mysql/eclass
/var/lib/layman/mysql/metadata
/var/lib/layman/mysql/profiles
/var/lib/layman/mysql/virtual

When I next ran the emerge command, it began by outputting:

Performing Global Updates
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  #='/var/db update'  @='/var/db move'
  s='/var/db SLOT move'  %='binary move'  S='binary SLOT move'
  p='update /etc/portage/package.*'
/var/lib/layman/mysql/profiles/updates/3Q-2014.

But still my edits were ignored. — How can I edit this .eclass file so that my edits actually take effect? Or how else can I work around an error like this?

Answer 1

Two possible ways. The first is easier but untested:

Easy way: Install a supported version and upgrade to an unsupported one

The error in this case occurs during a clean installation of an unsupported version of MySQL. It occurs when running the command emerge --config which is run after a clean installation as opposed to an upgrade. Therefore the easiest workaround is probably to first install an older, supported version of MySQL from the main repository; then upgrade it to the later, unsupported version from the overlay. So:

$ emerge --ask --verbose dev-db/mysql

Verify it asks to install a supported version. Let it run, then complete the installation as instructed:

$ emerge --config =dev-db/mysql-SUPPORTED.VERSION

Now unmask the later, unsupported version from the overlay repository, and upgrade to it:

$ emerge --ask --verbose dev-db/mysql

Verify the version it offers, and again let it run. That should work, though I haven't tested it; instead I did it the hard way.

Hard way: Override the eclass and deal with the errors

The developer manual says, ‘If an ebuild defines a function that is exported, this gets priority over any eclass version. This can be used to override eclass-defined defaults’. So copy mysql-5.7.12.ebuild from the ‘mysql’ overlay to your local overlay (priority +1000 in my case) and modify it there, appending the override:

pkg_config() { # test override of mysql-multilib-r1_pkg_config
    die "ebuild override works!";
}

Verify that Portage will run the ebuild:

$ equery which dev-db/mysql
/usr/local/portage/dev-db/mysql/mysql-5.7.12.ebuild

Then test it:

$ emerge --ask --unmerge dev-db/mysql
$ rm --recursive /var/lib/mysql/* # clean away any remnants
$ emerge --ask --verbose dev-db/mysql
    ⋮                                     # waiting while it compiles …
$ emerge --config =dev-db/mysql-5.7.12

Sure enough, it dies with the message ‘ebuild override works!’.

Now if you edit the ebuild file to do something more useful than dying, then redo the last command above, you'll see that it still dies with the same message. The Portage cache remains a problem. But since this is an ebuild file, not an eclass, and since it's in your own local overlay, you can easily work around the cache by using proper ebuild revisions:

$ pwd
/usr/local/portage/dev-db/mysql
$ cp mysql-5.7.12.ebuild mysql-5.7.12-r1.ebuild

And in the revision file mysql-5.7.12-r1.ebuild, edit pkg_config to implement the real fix:

pkg_config() { # modified from mysql-multilib-r1.eclass
               # of http://gpo.zugaina.org/Overlays/mysql
    einfo "Overriding mysql-multilib-r1_pkg_config from this ebuild"
      ⋮
  # initialize_options="--initialize-insecure  '--init-file=${sqltmp}'" # fix:
    initialize_options="--initialize-insecure   --init-file=${sqltmp} "
      ⋮
}

Then re-test it:

$ rm --recursive /var/lib/mysql/* # clean away any remnants
$ emerge --ask --verbose dev-db/mysql
    ⋮                                     # waiting while it recompiles …
$ emerge --config =dev-db/mysql-5.7.12-r1

Here it turns out that pkg_config still has errors:

[ERROR] Failed to open the bootstrap file /var/tmp/portage/ … tmp.PD6hqOe8kA
[ERROR] 1105  Bootstrap file error, return code (0). Nearest query: …

Probably it's file permissions. Anyway, it works if you re-run the failed command as root:

$ /usr/sbin/mysqld --basedir=/usr \
  --loose-skip-grant-tables --loose-skip-host-cache --loose-skip-name-resolve \
  --loose-skip-networking --loose-skip-slave-start --loose-skip-ssl \
  --loose-skip-log-bin --loose-skip-relay-log --loose-skip-slow-query-log \
  --loose-skip-external-locking --loose-skip-log-slave-updates \
  --user=mysql --datadir=/var/lib/mysql --tmpdir=/tmp/ --initialize-insecure \
  --init-file=/var/tmp/portage/dev-db/mysql-5.7.12-r1/temp/tmp.PD6hqOe8kA

Then carry on, manually interpreting and executing the Python code:

$ chown -R mysql:mysql /var/lib/mysql
$ chmod 0750 /var/lib/mysql
$ /usr/sbin/mysqld
  --loose-skip-grant-tables --loose-skip-host-cache --loose-skip-name-resolve \
  --loose-skip-networking --loose-skip-slave-start --loose-skip-ssl \
  --loose-skip-log-bin --loose-skip-relay-log --loose-skip-slow-query-log \
  --loose-skip-external-locking --loose-skip-log-slave-updates \
  --user=mysql --log-warnings=0 --basedir=/usr --datadir=/var/lib/mysql \
  --max_allowed_packet=8M --net_buffer_length=16K \
  --default-storage-engine=MyISAM \
  --socket=/var/run/mysqld/mysqld99.sock \
  --pid-file=/var/run/mysqld/mysqld99.pid \
  --tmpdir=/tmp/ &

Verify that socket file (above) is created. Then:

$ /usr/bin/mysql --socket=/var/run/mysqld/mysqld99.sock -hlocalhost -e \
  "UPDATE mysql.user SET Password = PASSWORD('your-password-here') WHERE USER='root'; FLUSH PRIVILEGES"

Here it fails with:

ERROR 1054 (42S22) at line 1: Unknown column 'Password' in 'field list'

I found the fix on Stack Overflow:

$ /usr/bin/mysql --socket=/var/run/mysqld/mysqld99.sock -hlocalhost -e \
  "UPDATE mysql.user SET authentication_string = PASSWORD('your-password-here') WHERE USER='root'; FLUSH PRIVILEGES"

Finally, terminate mysqld:

$ kill $(< /var/run/mysqld/mysqld99.pid ) # from the --pid-file above

That's it. Now you can add MySQL to a runlevel, or start and stop it manually:

$ /etc/init.d/mysql start
$ /etc/init.d/mysql stop

Answer 2

I'm not entirely sure what you're doing here, but an important point should be made:

If you're not re-emerging mysql before running --config, the config you use will be read, not out of any of your eclasses in your overlay, but from the files in /var/db/pkg/*/*/environment.bz2

Installing a package does some really cute tricks, for instance, if you write an ebuild and export a variable in src_compile ... that variable will likely still be accessible during pkg_config

If you have a poke around in that environment.bz2 file, you'll see all the inlined mysql eclass functions.

Hence, as you stated in your other answer, upgrading appears to fix it.

But it fixes it by replacing the installed copies of the eclass code :)