Bug 1364029

*** This bug has been marked as a duplicate of bug 1355764 ***

While, I get the reason why this is a duplicate (even when this file isn't mentioned in the original bug thread), it would be great to know why there are so many entries of "logging being initialized" instead of being logged somewhere else (if it could) or not being logged.

I agree. It's a sad fact that instead of improving yum, it's been replaced with a worse tool, one that doesn't even produce usable log files. Even the cheapest admin scripts have some sort of logging, but we're not talking about a cheap admin script, we're talking about *the* software management tool, which is a core component. It's absolutely essential to have a working software management tool. Note that "working" does not mean that a newly written replacement calls rpm correctly without crashing. If there's a reason to rewrite the whole thing from scratch, everything that was tested in the old version must be tested once again. If bugs are found, they have to be fixed - if this tool is the new one-and-only tool to be used (as it replaces yum). If yum could still be used, a buggy new alternative wouldn't be that bad.

This isn't like a desktop environment that can be switched. When using KDE and there are bugs that are annoying, one could switch to MATE until those bugs are fixed. But there's no system-switch-package-manager. This isn't even about desktop systems. Imagine someone is running a Fedora server system, he's running a release upgrade twice a year to be up to date and then some update broke something. He'd urgently need to find out what happened, which package version was replaced. So he opens the log and all he sees is "INFO --- logging initialized ---" but no info about the updated package. I'm pretty sure that would be the last time this person ever used Fedora on a server system.

As for the missing logs:
For example, I ran an upgrade from 28 to 29 yesterday. I've also tried to reinstall some other package. I can't find anything in the log:

[root@HOST log]# grep -cv "logging initialized" /var/log/dnf.rpm.log
8
[root@HOST log]# grep -v "logging initialized" /var/log/dnf.rpm.log
2018-11-26T12:08:36Z INFO Upgrade: kmod-VirtualBox-4.18.14-200.fc28.x86_64-5.2.22-1.fc29.x86_64
2018-11-26T12:08:40Z INFO warning: Unable to get systemd shutdown inhibition lock: Failed to connect to socket /run/dbus/system_bus_socket: Connection refused

2018-11-26T12:08:40Z INFO Upgrade: kmod-VirtualBox-4.18.14-200.fc28.x86_64-5.2.22-1.fc29.x86_64
2018-11-26T12:08:40Z INFO Upgraded: kmod-VirtualBox-4.18.14-200.fc28.x86_64-5.2.18-3.fc28.x86_64
2018-11-26T12:08:40Z INFO Upgraded: kmod-VirtualBox-4.18.14-200.fc28.x86_64-5.2.18-3.fc28.x86_64
2018-11-26T12:10:06Z INFO Installed: kmod-VirtualBox-4.19.2-301.fc29.x86_64-5.2.22-1.fc29.x86_64
2018-11-26T12:10:11Z INFO Installed: kmod-VirtualBox-4.19.2-301.fc29.x86_64-5.2.22-1.fc29.x86_64

But lots of debug messages (which are fine in a dev environment but not on a production system):

[root@HOST log]# grep -c "logging initialized" /var/log/dnf.rpm.log
68

The log begins a day before I ran the upgrade:

# head -n1 /var/log/dnf.rpm.log
2018-11-25T03:25:04Z INFO --- logging initialized ---

This bug was opened (and closed) two years ago and it doesn't seem like a product manager or developer has seriously looked at this. Suppose it wasn't a problem (it is), all questions would be answered and the bug report would've been closed a long time ago. But instead, the bug report, like many others, is floating around until people stop updating the "version" box at which point it'll be closed automatically by a bot who feels sorry about that:
"Thank you for reporting this bug and we are sorry it could not be fixed."