require essential libraries so broken 3rd party won't replace them

[MichaelMraka]

… (RhBug:1284349)(RhBug:1338921)

[ignatenkobrain]

not sure if it's good idea.

[ssssam]

I got hit by this problem (bad Hipchat RPM bundled a copy of sqlite, so DNF decided to remove my system sqlite and thus broke itself). If Fedora allows installing arbitrary 3rd-party RPMs then DNF really does need to safeguard against bad ones.

The proposed fix seems simple and effective to me if it works -- although I don't understand enough about DNF to know why adding depends to the .spec file would prevent 3rd party RPMs replacing system libraries...

[ignatenkobrain]

@ssssam that's the point, that only in some cases it will help (if there is something provides .so) but if I will put in my cool-pkg Provides: sqlite-libs it will not help. sqlite-libs will be replaced and dnf will be broken.

I think good idea is to start using vendorlocking functionality from libsolv.

[sdherr]

@ignatenkobrain but now you're making the jump from "the autogenerated Provides occasionally break everything" to "if people are intentionally and manually breaking things then things break". You can't prevent the latter case, no matter what you do. But we do need some way to prevent the install from blowing up in the face of removing sub-optimal 3rd party packages.

[ssssam]

In the case of Hipchat 2.0, it seems to explicitly Provide those things:

$ rpm -q --provides hipchat
aspell.so()(64bit)
hipchat = 2.2.1388-1
hipchat(x86-64) = 2.2.1388-1
hunspell.so()(64bit)
libKF5IdleTime.so.5()(64bit)
libKF5SonnetCore.so.5()(64bit)
libKF5SonnetUi.so.5()(64bit)
libKF5WindowSystem.so.5()(64bit)
libQt5Core.so.5()(64bit)
libQt5DBus.so.5()(64bit)
libQt5Gui.so.5()(64bit)
libQt5Network.so.5()(64bit)
libQt5OpenGL.so.5()(64bit)
libQt5Positioning.so.5()(64bit)
libQt5PrintSupport.so.5()(64bit)
libQt5Qml.so.5()(64bit)
libQt5Quick.so.5()(64bit)
libQt5Sensors.so.5()(64bit)
libQt5Sql.so.5()(64bit)
libQt5WebKit.so.5()(64bit)
libQt5WebKitWidgets.so.5()(64bit)
libQt5Widgets.so.5()(64bit)
libQt5X11Extras.so.5()(64bit)
libQt5Xml.so.5()(64bit)
libadl_sdk.so()(64bit)
libcanberra-alsa.so()(64bit)
libcanberra-multi.so()(64bit)
libcanberra-null.so()(64bit)
libcanberra-oss.so()(64bit)
libcanberra.so.0()(64bit)
libcanberra.so.0(CANBERRA_0)(64bit)
libcomposeplatforminputcontextplugin.so()(64bit)
libcrypto.so.1.0.0()(64bit)
libcrypto.so.1.0.0(OPENSSL_1.0.0)(64bit)
libcrypto.so.1.0.0(OPENSSL_1.0.1)(64bit)
libcrypto.so.1.0.0(OPENSSL_1.0.1d)(64bit)
libdbusmenu-qt5.so.2()(64bit)
libibusplatforminputcontextplugin.so()(64bit)
libicudata.so.52()(64bit)
libicui18n.so.52()(64bit)
libicuuc.so.52()(64bit)
liblzma.so.5()(64bit)
liblzma.so.5(XZ_5.0)(64bit)
libogg.so.0()(64bit)
libpng16.so.16()(64bit)
libpng16.so.16(PNG16_0)(64bit)
libqconnmanbearer.so()(64bit)
libqgenericbearer.so()(64bit)
libqgif.so()(64bit)
libqico.so()(64bit)
libqjpeg.so()(64bit)
libqnmbearer.so()(64bit)
libqtaccessiblequick.so()(64bit)
libqtaccessiblewidgets.so()(64bit)
libqtquick2plugin.so()(64bit)
libqxcb.so()(64bit)
libqxmpp.so.0()(64bit)
libsqlite3.so.0()(64bit)
libssl.so.1.0.0()(64bit)
libssl.so.1.0.0(OPENSSL_1.0.0)(64bit)
libssl.so.1.0.0(OPENSSL_1.0.1)(64bit)
libssl.so.1.0.0(OPENSSL_1.0.1d)(64bit)
libstdc++.so.6()(64bit)
libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(CXXABI_1.3.1)(64bit)
<snip loads more things>

The description says "This is an installer created using CPack (http://www.cmake.org)." so it's probably CPack being broken, rather than a deliberate malicious RPM. Worth noting that I'm also using quite an old Hipchat RPM (the new version segfaults, but that's a whole different story) so I don't know if things are fixed upstream.

[mluscon]

@ignatenkobrain any idea what happened with the CI?

[mluscon]

jenkins retest this please

[sdherr]

@ssssam the fact that it lists them in the --provides output tells you nothing about whether they were explicit or implicit. Explicit means they were spelled out as a "Provides: " line in the spec file. Implicit means that the build scripts searched the rpm to see what binary libraries it contains and automatically added them.

Any .so. library, either in --provides or --requires, was almost certainly added automatically by the build scripts. And that behavior is present in the base rpmbuild and similar packages too, so it's almost certainly not CPack's fault.

This is very much a problem with dnf not correctly handling behavior that has been automatic, default, and consistent since forever, and as such dnf needs to figure out how to work correctly and not blow up innocent user's systems.

[mluscon]

I merged this only as a temporary workaround. We still need to figure out some general solution.

[ignatenkobrain]

/me still don't agree with this because if anyone adds Provides: sqlite then fedoras sqlite will be autoremoved.

[ignatenkobrain]

this is proper way of fixing problem: openSUSE/libsolv#138