How do I check why a dependency got pulled into a zypper dup?
The massive GCC5 update suddenly installed mariadb (which advertises itself MySQL which it isn’t, it’s a MySQL replacement):
Message from package mariadb:</code>
You just installed MySQL server for the first time.
You can start it using:
rcmysql start
During first start empty database will be created for your automatically.
PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !
To do so, start the server, then issue the following commands:
'/usr/bin/mysqladmin' -u root password 'new-password'
'/usr/bin/mysqladmin' -u root -h misibook password 'new-password'
Alternatively you can run:
'/usr/bin/mysql_secure_installation'
which will also give you the option of removing the test
databases and anonymous user created by default. This is
strongly recommended for production servers.
Thanks a lot. Seems there is no dependency (see below).
But this got me thinking: could this be the “Web and LAMP Server” pattern got extended? It wasn’t a replacement of mysql with mariadb (see the zypper dup log further below).
**revue:/etc #** zypper rm mariadbLoading repository data...
Reading installed packages...
Resolving package dependencies...
The following package is going to be REMOVED:
mariadb
1 package to remove.
After the operation, 78.7 MiB will be freed.
**Continue? [y/n/? shows all options] (y): y**
(1/1) Removing mariadb-10.0.17-1.3 .....................................................................................................................................................................................................[done]
You are right. But it also leads to new questions.
I went through my original log of installation screenshots. It indeed installed mariadb, but it did not give any message about manual security modifications needed.
So: since when is that required? and why?
Would the big GCC5 update have caused this?
This message is printed on installation or update of the package if no database tables exist.
It should have been printed during the original installation too.
The question is whether this makes sense on updates…
So: since when is that required? and why?
It is not really required.
It is just recommended for security reasons. The default is to allow the mysql root user root to connect without a password (but from localhost only, as listening on the network is turned off by default), obviously you wouldn’t want that on a mysql server in your network or the Internet…
But even with the default settings it might be problematic, as every local user can connect (with full powers) by specifying “root” as username, no password needed.
I doubt all other of 4115 installed packages do not really need glibc … you will need to loop through what mariadb provides if you want to go this route. Mandrake urpmq was excellent in giving recursive dependency information.
Packages require the libraries directly, not some specific lib package, at least for the dependencies auto-generated by rpmbuild.
So, packages require i.e. libc.so.6, not glibc.
Try “rpm -q --whatrequires libc.so.6” and you’ll get a much longer list…
But of course, you will miss packages then that do require glibc, and not libc.so.6.
Another option would be to use zypper though:
zypper se -i --requires glibc
This will list all installed packages (’-i’ means to only list installed ones) that require the package glibc.
And “zypper se” also has these options: --recommends, --conflicts, --suggests, --obsoletes
I think you can even combine several into one query.
But even with zypper, “zypper se --requires mariadb” won’t find much (only the mariadb packages themselves, and the akonadi source package), you need to specify “mysql” as well. In the case of glibc and other libraries, it seems to be fine though.
bor@opensuse:~> LC_ALL=C LANG=C zypper --no-refresh se -i --requires --match-exact glibc
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+--------------+-----------------------------------------------------+--------
i | glibc-devel | Include Files and Libraries Mandatory for Develop-> | package
i | glibc-extra | Extra binaries from GNU C Library | package
i | glibc-locale | Locale Data for Localized Programs | package
i | liblockdev1 | The header files for the lockdev library | package
i | nscd | Name Service Caching Daemon | package
i | valgrind | Memory Management Debugger | package
bor@opensuse:~>
It looks like it returns all packages because by default zypper does case insensitive substring search and so matches something like
But I’d say that’s exactly what you want in this case, i.e. for finding out what requires glibc.
And it should also work with other lib packages, as a package would either require libxxx or libxxx.so.x.
It does no miracles.
Of course it doesn’t.
But I suppose URPM does neither…
Never used that though, so I’m not really sure what you mean exactly with “recursive dependencies search”.
That package x is listed as requiring z, if it requires y which in turn requires z?
For that “zypper rm” as you wrote (maybe with the --dry-run/-D option) is probably the best way, yes.
Or “rpm -e --test xxx”.
bor@opensuse:~> LC_ALL=C LANG=C zypper --no-refresh se -i --requires libopenssl1_0_0
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+------------------+-------------------------------------------------+--------
i | libopenssl-devel | Include Files and Libraries mandatory for Dev-> | package
bor@opensuse:~> rpm -q --provides libopenssl1_0_0
libcrypto.so.1.0.0()(64bit)
libgost.so()(64bit)
libopenssl1_0_0 = 1.0.1k-2.24.1
libopenssl1_0_0(x86-64) = 1.0.1k-2.24.1
libpadlock.so()(64bit)
libssl.so.1.0.0()(64bit)
bor@opensuse:~> LC_ALL=C LANG=C zypper --no-refresh se -i --requires 'libssl.so.1.0.0()(64bit)'
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
--+----------------------------+---------------------------------------+--------
i | cups | The Common UNIX Printing System | package
i | cups-libs | Libraries for CUPS | package
i | git-core | Core git tools | package
i | gnome-vfs2 | The GNOME 2.x Desktop Virtual File -> | package
... long list
But I suppose URPM does neither…
When user asks question “which packages require package foo” user is actually interested in answer similar to"can I remove package foo without breaking my system", or, in reverse, “what packages must I install additionally if I want to install package foo”. zypper answers different question - what package has “provide” attribute that matches string “foo”. This is entirely different and too low level to be of real use. It is useful, but for a developer, not a user.
urmpq gave exactly the right answer. “urpmq --requires foo” prints the list of packages that require package foo. This is effectively
for i in $(rpm -q --provides foo); do
zypper search --match-exact $i
done
except zypper does not provide nice scripting interface for it.
That package x is listed as requiring z, if it requires y which in turn requires z?
That was “urpmq --requires-recursive”. It is effectively list you get when you try “zypper rm”.
