On 4 March 2010 15:57, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On Thursday 04 March 2010 17:37:23 Mick wrote: >> I am trying to understand what is pulling in mysql again. This >> morning a load of qt packages were being updated and I noticed a bunch >> of perl and virtual packages in there too. Rest assured dev-db/mysql >> was in there, again. This is despite the fact that the mysql use flag >> seem to be not active as far as portage is concerned: >> >> # euse -i mysql >> global use flags (searching: mysql) >> ************************************************************ >> [- ] mysql - Adds mySQL Database support >> >> local use flags (searching: mysql) >> ************************************************************ >> [- ] mysql (app-admin/ulogd): >> Build MYSQL output plugin to save packets in a mysql database. >> >> [- ] mysql (net-misc/mediatomb): >> Use dev-db/mysql as backend rather than SQLite3. If this USE flag is >> disabled, dev-db/sqlite is used in its stead. >> >> Looking into it further I see that the virtual package is pulling the >> database in: >> >> # equery depends dev-db/mysql >> [ Searching for packages depending on dev-db/mysql... ] >> virtual/mysql-5.0 (=dev-db/mysql-5.0*) >> >> # equery depends virtual/mysql >> [ Searching for packages depending on virtual/mysql... ] >> dev-db/mysql-5.0.84-r1 (=virtual/mysql-5.0) >> dev-libs/cyrus-sasl-2.1.23-r1 (mysql? virtual/mysql) >> dev-libs/redland-1.0.10-r1 (mysql? virtual/mysql) >> dev-perl/DBD-mysql-4.00.5 (virtual/mysql) >> x11-libs/qt-sql-4.6.2 (mysql? virtual/mysql) >> >> So, is this telling me the virtual mysql package depends of the real >> mysql and vice versa? Should I give up and accept that just like a >> LAMP build, from now on a Linux desktop *must* run mysql and nothing >> else will do? I've read that sqlite is borked and won't do what >> semantic-desktop wants, but what about people who for arguments sake >> want to run postgress or some other database? > > The tool you want to answer this question is > > emerge -t
Right, but I started this mammoth emerge before I spent enough time looking at its contents I'm afraid. :-( I could of course uninstall them and try again, but there's steam coming out the back of this old box and I would rather not have to rinse and repeat. This is what was pulled in today and most of the perl stuff seemed like new installs: Thu Mar 4 09:20:24 2010 >>> dev-libs/libffi-3.0.9 Thu Mar 4 09:20:49 2010 >>> dev-db/mysql-init-scripts-1.2 Thu Mar 4 09:26:49 2010 >>> net-dns/bind-tools-9.4.3_p5 Thu Mar 4 09:33:38 2010 >>> dev-perl/Net-Daemon-0.43 Thu Mar 4 09:34:57 2010 >>> perl-core/Storable-2.20 Thu Mar 4 09:35:22 2010 >>> dev-perl/yaml-0.68 Thu Mar 4 09:35:56 2010 >>> perl-core/Test-Harness-3.17 Thu Mar 4 09:36:32 2010 >>> perl-core/Package-Constants-0.02 Thu Mar 4 09:37:07 2010 >>> perl-core/Sys-Syslog-0.27 Thu Mar 4 09:37:26 2010 >>> virtual/perl-Storable-2.20 Thu Mar 4 09:37:41 2010 >>> virtual/perl-Test-Harness-3.17 Thu Mar 4 09:37:57 2010 >>> virtual/perl-Package-Constants-0.02 Thu Mar 4 09:38:15 2010 >>> virtual/perl-Sys-Syslog-0.27 Thu Mar 4 09:38:46 2010 >>> dev-perl/PlRPC-0.2020-r1 Thu Mar 4 09:39:19 2010 >>> perl-core/IO-Zlib-1.09 Thu Mar 4 09:39:35 2010 >>> virtual/perl-IO-Zlib-1.09 Thu Mar 4 09:40:09 2010 >>> perl-core/Archive-Tar-1.54 Thu Mar 4 09:40:27 2010 >>> virtual/perl-Archive-Tar-1.54 Thu Mar 4 09:41:03 2010 >>> perl-core/Module-Build-0.34.0201 Thu Mar 4 09:41:19 2010 >>> virtual/perl-Module-Build-0.34.0201 Thu Mar 4 09:41:52 2010 >>> perl-core/ExtUtils-CBuilder-0.26.03 Thu Mar 4 09:42:08 2010 >>> virtual/perl-ExtUtils-CBuilder-0.26.03 Thu Mar 4 09:42:48 2010 >>> perl-core/File-Spec-3.30 Thu Mar 4 09:43:21 2010 >>> perl-core/ExtUtils-ParseXS-2.20.0401 Thu Mar 4 09:43:37 2010 >>> virtual/perl-ExtUtils-ParseXS-2.20.0401 Thu Mar 4 09:43:53 2010 >>> virtual/perl-File-Spec-3.30 Thu Mar 4 09:44:48 2010 >>> dev-perl/DBI-1.609 Thu Mar 4 09:47:31 2010 >>> dev-util/boost-build-1.41.0 Thu Mar 4 09:55:19 2010 >>> media-gfx/exiv2-0.19 Thu Mar 4 11:49:55 2010 >>> dev-libs/boost-1.41.0-r3 Thu Mar 4 12:29:27 2010 >>> dev-db/mysql-5.0.84-r1 Thu Mar 4 12:29:44 2010 >>> virtual/mysql-5.0 Thu Mar 4 12:30:32 2010 >>> dev-perl/DBD-mysql-4.00.5 Thu Mar 4 13:08:28 2010 >>> x11-libs/qt-core-4.6.2-r1 Thu Mar 4 13:12:49 2010 >>> x11-libs/qt-dbus-4.6.2 Thu Mar 4 13:28:44 2010 >>> x11-libs/qt-script-4.6.2 Thu Mar 4 13:32:06 2010 >>> x11-libs/qt-sql-4.6.2 Thu Mar 4 13:33:58 2010 >>> x11-libs/qt-test-4.6.2 Thu Mar 4 14:01:18 2010 >>> x11-libs/qt-xmlpatterns-4.6.2 Thu Mar 4 15:45:26 2010 >>> x11-libs/qt-gui-4.6.2 Thu Mar 4 16:11:12 2010 >>> x11-libs/qt-qt3support-4.6.2 Thu Mar 4 16:17:31 2010 >>> x11-libs/qt-opengl-4.6.2 Thu Mar 4 16:21:11 2010 >>> x11-libs/qt-svg-4.6.2 > There will be a reason why mysql is being pulled in, most likely a package > that must have it. If a package must have it, wouldn't the USE flag mysql switch to + ? > If a user wants postgres, he should install and run postgres. How would this > affect the presence or absence of mysql? Well, I am assuming that if postgres can do what mysql does, then it could work in its place. Like if syslog-ng will do what metalog does, then the virtual/log-thingie will not insist in pulling in metalog. Anyway, the postgres is just an example of asking why are we locking down the choice of a database to a particular package/provider. I am thinking that x11-libs/qt-sql-4.6.2 may be what started this emerge of mysql. -- Regards, Mick