Rpm mysql-server isn't priority of this content. Configuration files are under rpm mysql-lib. However, content requires installed mysql due to binary:
  /usr/bin/my_print_defaults

But mysql-libs are required by other packages too. So, I recommend set applies_to for mysql-libs and inside check script check if mysql is installed. When mysql isn't installed, we should probably print some info with *_risk, that content can't check configuration files and ask for installation of mysql rpm first.

What do you thinkg Lojzo about that solution?

Seems OK to me.

What kinda sucks is that in case mysql-libs are present but the binary isn't, we'll have to blackmail user (into installing the server which we'll be migrating then) ... but I don't see any better solution.

We might want to think about generic solution to such situation (dependency X needed to analyze files of Y) but for this bug the above seems OK.

(In reply to Alois Mahdal from comment #3)
....
> We might want to think about generic solution to such situation (dependency
> X needed to analyze files of Y) but for this bug the above seems OK.

I agree. We have now something like that - in INI files we can use "binary_req" or "requires" I don't like the output here. It's too generic:

,,INPLACERISK: HIGH: Binary /usr/bin/my_print_defaults is not installed"

I'll discuss it with Peter, if it is possible change the default message or append specific description for each content.

Ok. So we will use more general solution. binary_req in INI file will be set and better message will be provided by preupgrade-assistant.

After discussion, there is set requirements on mysql package which provides the binary (above) instead of binary_req.

That's because we want to rather print package which should be installed instead of binary.

Tested with preupgrade-assistant-el6toel7-0.6.48-1.el6:

 *  If mysql is missing, followint two risks are logged:

        INPLACERISK: HIGH: Package mysql is not installed.
        INPLACERISK: HIGH: Please, install all required packages (and binaries) and run preupg again to process check properly.

 *  Otherwise, risks along with relevant .cnf file are printed according to
    particular option used.  This is the "lagrest" variant (all problematic
    options in place):

        INPLACERISK: MEDIUM: /etc/my.cnf: option 'plugin-load=innodb=' is not supported
        INPLACERISK: HIGH: /etc/my.cnf: option 'innodb_file_io_threads' is not supported
        INPLACERISK: HIGH: /etc/my.cnf: option 'language' is deprecated
        INPLACERISK: HIGH: /etc/my.cnf: option 'log-bin-trust-routine-creators' was removed in MariaDB 5.5
        INPLACERISK: HIGH: /etc/my.cnf: option 'table_lock_wait_timeout' was removed in MariaDB 5.5

        The files mentioned above are backups of your original configuration files.
        After the upgrade you must manually replace the contents of the default
        MariaDB 5.5 configuration (as is appropriate to your environment), with the
        information provided about replaced or deprecated options listed in the
        backups.  You must restart MariaDB for these changes to take effect.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-1020.html