The scriplet read /dev/urandom... perhaps can explain this.

@Haghighi can you test (which use another simpler version of the scriptlet)

dnf install https://rpms.remirepo.net/fedora/27/remi/x86_64/phpMyAdmin-4.7.4-1.fc27.remi.noarch.rpm

Haghighi, what environment is that? If the environment is not able to
provide 32 byte of entropy in a reasonable time...well, I'm honestly not
sure if such an environment is suitable for anything at all. But yes,
the testing result from Remi's package would still be interesting.

@Robert, the simpler scriptlet use

SECRET=$(printf "%04x%04x%04x%04x%04x%04x%04x%04x" $RANDOM $RANDOM $RANDOM $RANDOM $RANDOM $RANDOM $RANDOM $RANDOM)

(which still, of course, requires some entropy)

(In reply to Remi Collet from comment #1)
> The scriplet read /dev/urandom... perhaps can explain this.
> 
> @Haghighi can you test (which use another simpler version of the scriptlet)
> 
> dnf install
> https://rpms.remirepo.net/fedora/27/remi/x86_64/phpMyAdmin-4.7.4-1.fc27.remi.
> noarch.rpm

Remi's package installed correctly. and works fine.

Now I am even more interested what kind of environment that is. At least
it does not seem to provide reliable entropy. Is that a container?

(In reply to Robert Scheck from comment #5)
> Now I am even more interested what kind of environment that is. At least
> it does not seem to provide reliable entropy. Is that a container?

No
It is a normal PC
Intel® Core™ i5-2500K CPU @ 3.30GHz × 4 
Fedora workstation 27 x86_64
Linux 4.13.5-300.fc27.x86_64

(In reply to Remi Collet from comment #1)
> The scriplet read /dev/urandom... perhaps can explain this.
> 
I'm I wrong that reading from /dev/urandom is supposed to never block?

@Robert see negative comment on https://bodhi.fedoraproject.org/updates/FEDORA-2017-228d6fddb5

*** Bug 1485740 has been marked as a duplicate of this bug. ***

@Robert, I was able to reproduce on a fresj F27 VM, fully updated, and then dnf install phpMyAdmin (4.7.4 or 4.7.5)

Should be fixed by https://src.fedoraproject.org/cgit/rpms/phpMyAdmin.git/commit/?id=b8d324ba25223c90cd7fff44b2947b465e8206fa

@Remi, thanks, with this change it doesn't trigger the hang.

Interestingly, it was not triggering this hang if I ran the command of the scriptlet manually (I don't even have time to see the processes), but was doing it only in dnf.

It was doing it with downgrade, upgrade, and reinstall. 
Even if there was not MUSTBECHANGEDONINSTALL in the config file.

In top, there were all (cat/tr/fold) switching between status: R (running) and S (sleeping), but fold was the one the most active and was using 55% to 95% of my core2duo (even while sleeping).

phpMyAdmin-4.7.5-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-228d6fddb5

Problem solved in phpMyAdmin-4.7.5-2.fc27
Thank you all

Just asking...without having this verified: Could it be that SELinux is
blocking access to /dev/urandom when called by RPM?

Robert,

In my case, I have SELINUX "disabled" in the /etc/selinux/config file. That doesn't mean that selinux couldn't be involved though... parts of selinux could be checking incorrectly and "think" that selinux IS active when it is NOT.

Regards,

George...

So it's not SELinux specific, thanks George for letting us know.

Is phpMyAdmin-4.7.5-2.fc27 going to be available for F27 launch? I have several systems which are now hung dead during install because of phpMyAdmin. I have killed the fold process in the background to continue with the installs, but this should have been fixed by release, right?

@Nathan, the bug status in still "ON_QA", so not yet in the stable repository.

phpMyAdmin-4.7.5-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.