After upgrading perl to 5.8.6, I noticed DB_File.pm was in the 5.8.5 directory still. Running equery resulted in: mars peter # equery b DB_File.pm [ Searching for file(s) DB_File.pm in *... ] dev-lang/perl-5.8.6-r4 (/usr/lib/perl5/5.8.6/i686-linux/DB_File.pm) perl-core/DB_File-1.811 (/usr/lib/perl5/5.8.5/i686-linux/DB_File.pm) Some programs, like spamassassin still depend on the perl-core entry: mars peter # equery d DB_File [ Searching for packages depending on DB_File... ] mail-filter/spamassassin-3.0.4 A diff of the two files shows that the perl-core DB_File is a higher version: mars i686-linux # diff DB_File.pm /usr/lib/perl5/5.8.5/i686-linux/DB_File.pm 4,5c4,5 < # last modified 7th August 2004 < # version 1.810 --- > # last modified 12th March 2005 > # version 1.811.. Yet, no other differences were detected. Reproducible: Always Steps to Reproduce: 1. emerge -u perl... 2. run perl-cleaner all 3. check residual files in 5.8.5 Actual Results: DB_File.pm remains in 5.8.5/i686-linux Expected Results: Not sure. Should perl-cleaner have removed it? Should the perl-core DB_File be removed? Is DB_File a part of the perl installation now? Right now, I am not removing anything, but would appreciate some guidance. Thx
I had a great response about how equery had to be wrong because we install all addon modules into vendor_perl - and am wrong. But for the rest of that thread... --- We maintain an ebuild for those users that don't upgrade their perl, or that need a newer version than the one shipped with their perl. DB_File is unmasked up to at least the same level as perl 5.8.6. There's already a bug report for the perl-cleaner failing :) --- Now I see that DB_File is a bad ebuild, and this is what is confusing perl-cleaner...
Well, what happens if I unmerge DB_File? Will spamassassin, which specifically wants perl-core/DB_FILE try and re-emerge it? Or, will it cleverly know that it's included with the new 5.8.6 installation? WHat's the proper way to handle this? Thx
Hold on, -r1 of DB_File is on its way to the mirrors with a patch. The Makefile.PL had a hardcoded reference to install in the core perl dirs - overriding that with the patch, and all should be good again in the world of Gentoo.
OK, the -r1 emerge removed DB_File from the earlier perl dir. Now, are perl-core/DB_File and the DB_File installed by perl 5.8.6 mutually exclusive or should the DB_File package be removed by emerge -C? Should perl-cleaner be run again? Thx
They aren't mutually exclusive (or are they? guess it depends on your interpretation ;) The ebuild supercedes the version that came with 5.8.6 (and 5.8.5 and 5.8.4 and...). In this case, we provide 1.811, and 5.8.5 came with 1.809 and 5.8.6 came with 1.81(0). use DB_File will load the ebuild provided module (or should...you know how much fun reality can be at times)
Raises an interesting question then. If a program uses DB_File, but does not specify a minimum version, then shouldn't it accept that provided with Perl and NOT load the separate module? Take spamassassin, which is the app that started this whole bug for me. It requires DB_File berkdb? ( perl-core/DB_File )" But really, if this is the case, is perl-core really required? I realize this may be a spamassassin issue.
The ebuild exists because some module/apps depend on certain versions of a module - usually newer than what came with an average install of perl (assuming the users are keeping up to date and aren't still running 5.8.0 or less, in which case they have other problems). In the case of SA, when the dep was originally added, the ebuild by far superceded what came with the then unmasked perl. Additionally, we provide ebuilds for modules that contain security/functionality fixes - in which case anything that uses the module is tested and the dep'd so that your box is safe and free (yada yada yada, you know where i'm going with that)
closing this, fixed as much as it can be
