upgrade perl conflicts

[kilburna]

After sync, perl needs to be updated. Getting conflicts. Any ideas how to resolve this.

Code: Select all

EBox ~ # emerge -uDNav --keep-going=y @system --backtrack=30 

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U  ] dev-lang/perl-5.18.2-r1:0/5.18 [5.16.3:0/5.16] USE="berkdb gdbm -debug -doc -ithreads" 13,746 kB
[ebuild     U  ] app-admin/perl-cleaner-2.16 [2.15] 6 kB
[ebuild     U  ] sys-fs/udev-215-r1 [215] USE="acl firmware-loader kmod -doc -gudev -introspection (-selinux) -static-libs" ABI_X86="(64) (-32) (-x32)" 3 kB
[ebuild     U  ] virtual/udev-215 [208-r2] USE="(-gudev%) (-introspection%) (-static-libs%)" ABI_X86="(-32%) (-64%*) (-x32%)" 0 kB

Total: 4 packages (4 upgrades), Size of downloads: 13,755 kB

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

  (dev-lang/perl-5.16.3::gentoo, installed) pulled in by
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/DateManip-6.410.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/IO-Tty-1.110.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/WWW-RobotRules-6.20.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Sub-Exporter-0.986.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-vcs/git-1.8.5.5::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (perl-core/Archive-Tar-1.900.0-r1::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/DateTime-Format-Mail-0.300.100-r1::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/libwww-perl-6.50.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (net-analyzer/net-snmp-5.7.3_pre3::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/PlRPC-0.202.0-r2::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/DateTime-TimeZone-1.600.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/IO-Socket-SSL-1.953.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Net-SSLeay-1.550::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/HTTP-Negotiate-6.0.1-r1::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (perl-core/IO-1.25-r1::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/File-HomeDir-1.0.0-r1::gentoo, installed)
    dev-lang/perl:0/5.16= required by (net-print/cups-filters-1.0.53::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Net-Daemon-0.480.0-r1::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Geo-IP-1.420.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/File-Tail-0.99.3-r1::gentoo, installed)
    =dev-lang/perl-5.16* required by (virtual/perl-ExtUtils-Install-1.580.0-r1::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/DateTime-1.030.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Package-Stash-0.360.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Try-Tiny-0.180.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Package-Stash-XS-0.280.0::gentoo, installed)
    dev-lang/perl:0/5.16=[-build(-)] required by (dev-perl/Error-0.170.210::gentoo, installed)
    (and 1 more with the same problems)

  (dev-lang/perl-5.18.2-r1::gentoo, ebuild scheduled for merge) pulled in by
    =dev-lang/perl-5.18* required by (virtual/perl-Text-Balanced-2.20.0-r4::gentoo, installed)
    (and 31 more with the same problem)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

Thanks

[Budoka]

I had a similar problem today and ran

Code: Select all

emerge --update --newuse --deep --with-bdeps=y @world

and then

Code: Select all

emerge --depclean && revdep-rebuild

not sure if it is the best solution but it fixed the problem.

[kilburna]

Thanks for reply. I tried emerge --update --newuse --deep --with-bdeps=y @world and still the same problem.

[Budoka]

Thanks for reply. I tried emerge --update --newuse --deep --with-bdeps=y @world and still the same problem.

I am not sure why all those packages would be pulling in perl-5.16.3 given that portage is showing that

dev-lang/perl-5.18.2-r1

is the most recent version of perl.

Unfortunately someone more knowledgeable than I will have to weigh in here but maybe this will help. Sorry.

http://wiki.gentoo.org/wiki/Troubleshoo ... _Conflicts

You might also try perl-cleaner or un-merging perl and re-installing but not sure if that is the best solution. Just something I would try I were in the same boat.

[epsilon72]

I ran into a similar problem this week. I was trying to run ' perl-cleaner --reallyall ' after the perl 5.18 upgrade but kept running into blocks. An ' emerge --depclean ' removed a lot of what I assume were older perl packages, and now everything is fine.

Make sure you ' emerge --sync ' again before trying anything else.

[dataking]

I would guess that all of those packages are expecting perl 5.16, while portage is wanting to upgrade perl to 5.18. A rather heavy handed approach would be to unmerge all those packages; upgrade perl, and reinstall them.

[steveL]

I think you need to do perl as a package on its own, along with a couple of others, before you do the cleaner:

Code: Select all

emerge -1 dev-lang/perl virtual/perl-ExtUtils-Install virtual/perl-ExtUtils-MakeMaker dev-perl/extutils-pkgconfig

ExtUtils-Install is in your list above, and MakeMaker I saw in a recent post I can't find right now, extutils-pkgconfig (the ExtUtils-PkgConfig module) in [topic=996716]this one[/topic] -- it's not a virtual, but is needed to build other modules.

If you have eix it might be better to do all the installed virtual/perl-ExtUtils ones instead. You can see them with:

Code: Select all

eix '-I#' virtual/perl-ExtUtils

and we'd incorporate it into the above as:

Code: Select all

emerge -1 dev-lang/perl $(eix '-I#' virtual/perl-ExtUtils) dev-perl/extutils-pkgconfig

If you've done perl already you can ofc take it out of the command and just do this before running perl-cleaner:

Code: Select all

emerge -1 $(eix '-I#' virtual/perl-ExtUtils) dev-perl/extutils-pkgconfig

At least that's how I'm approaching this so far in update to automate the sequence (working on it atm for people on 5.12 as well as 5.16.)

You can use esearch too, but we just use the vdb, cache, q or eix in script, so someone else will have to come up the stanza for that.

If anyone has more ideas or can point out flaws, please do share.

I'm not sure about depclean, as it has to run after you've done the full world upgrade, and perl has to be working before you do that, though I guess you do the cleaner after the world upgrade to catch anything that's been missed. Hmm.

HTH,
steveL.

[gienah]

Expanding on steveL's suggestion, an idea that might be worth a try is to try emerging perl
along with all the virtual/perl packages, with the -av option to see if emerge can figure it out:

Code: Select all

EIX_LIMIT=0 emerge -auvDN -1 =dev-lang/perl-5.18* $(eix '-I#' virtual/perl-*)

[steveL]

Ah nice one gienah; you're right about selecting the later perl version we need, as otherwise portage might pull in the older one to avoid blockages. You should quote the eix argument to avoid globbing as a general rule though: eix '-I#' 'virtual/perl-*'

I'm not seeing any difference here with EIX_LIMIT=0; perhaps it doesn't matter with virtuals. Not sure exactly what it does, tbh, though I've seen mv use it in examples.

dev-perl/extutils-pkgconfig doesn't have a virtual afaik, unless I'm missing it in those other ones.

edit: Recommended

Code: Select all

emerge -1 -avDN $(eix '-I#' 'virtual/perl-*') dev-perl/extutils-pkgconfig

[topic=996774]in this topic[/topic] (2nd post); as stated I'm not sure about -u as we want things to be rebuilt.

Can someone tell me whether we should add -u? Preferably with an explanation.

Thanks.

[gienah]

Ah nice one gienah; you're right about selecting the later perl version we need, as otherwise portage might pull in the older one to avoid blockages. You should quote the eix argument to avoid globbing as a general rule though: eix '-I#' 'virtual/perl-*'

Thanks for explaining the need for the quotes.

I'm not seeing any difference here with EIX_LIMIT=0; perhaps it doesn't matter with virtuals. Not sure exactly what it does, tbh, though I've seen mv use it in examples.

eix told me it wanted EIX_LIMIT=0:

Code: Select all

# eix '-I#' 'virtual/perl-*'
virtual/perl-Archive-Tar
virtual/perl-Attribute-Handlers
virtual/perl-CGI
virtual/perl-CPAN-Meta
virtual/perl-CPAN-Meta-Requirements
virtual/perl-CPAN-Meta-YAML
virtual/perl-Compress-Raw-Bzip2
virtual/perl-Compress-Raw-Zlib
virtual/perl-Digest
virtual/perl-Digest-MD5
virtual/perl-Digest-SHA
virtual/perl-Encode
virtual/perl-ExtUtils-CBuilder
virtual/perl-ExtUtils-Command
virtual/perl-ExtUtils-Install
virtual/perl-ExtUtils-MakeMaker
virtual/perl-ExtUtils-Manifest
virtual/perl-ExtUtils-ParseXS
virtual/perl-File-Path
virtual/perl-File-Spec
virtual/perl-File-Temp
virtual/perl-Getopt-Long
virtual/perl-IO
virtual/perl-IO-Compress
virtual/perl-IO-Zlib
virtual/perl-IPC-Cmd
virtual/perl-JSON-PP
virtual/perl-Locale-Maketext-Simple
virtual/perl-MIME-Base64
virtual/perl-Math-BigInt
virtual/perl-Math-BigInt-FastCalc
virtual/perl-Math-BigRat
virtual/perl-Module-Build
virtual/perl-Module-CoreList
virtual/perl-Module-Load
virtual/perl-Module-Load-Conditional
virtual/perl-Module-Metadata
virtual/perl-Net-Ping
virtual/perl-Package-Constants
virtual/perl-Params-Check
virtual/perl-Parse-CPAN-Meta
virtual/perl-Perl-OSType
virtual/perl-Pod-Escapes
virtual/perl-Pod-Parser
virtual/perl-Pod-Simple
virtual/perl-Scalar-List-Utils
virtual/perl-Storable
virtual/perl-Sys-Syslog
virtual/perl-Test-Harness
virtual/perl-Test-Simple
Only 50 matches displayed on terminal.
Set EIX_LIMIT=0 to show all matches.
#

dev-perl/extutils-pkgconfig doesn't have a virtual afaik, unless I'm missing it in those other ones.

Oh, I was wondering why you added it.

Recommended

Code: Select all

emerge -1 -avDN $(eix '-I#' 'virtual/perl-*') dev-perl/extutils-pkgconfig

Looks promising, thanks.

I'm not sure about -u as we want things to be rebuilt.

Duh, true, sorry for the confusion.

[Hu]

The line before the mention of EIX_LIMIT is also important. To avoid flooding the display when you use a match with many hits, eix limits itself to 50 results. When the output is not to a terminal, this limit is not enforced, since it is assumed that you piped the output to a program which can handle receiving all the matches.

[steveL]

Ah that explains it, thanks. I certainly don't have that many virtual/perl-*, and mostly use eix from script in any case.

[jlpoole]

Is there an explanation somewhere as to the design of handling Perl and it's packages within Gentoo?

I'm running:

themis / # uname -a
Linux themis 3.12.13-gentoo #1 SMP Thu Apr 10 15:16:31 PDT 2014 x86_64 Intel(R) Core(TM) i5 CPU M 460 @ 2.53GHz GenuineIntel GNU/Linux
themis / #

which has enough problem being an X64 system. What I am finding is that the virtual/perl... packages have fixed dependences. For example:

virtual/perl-Perl-OSType version 1.2.0-r2 has hard-coded 5.16:

Code: Select all

RDEPEND="
17 	|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )

where as its successor, virtual/perl-Perl-OSType version 1.3.0-r1 has hard-code 5.18:

Code: Select all

16 	RDEPEND="
17 	|| ( =dev-lang/perl-5.18* ~perl-core/${PN#perl-}-${PV} )

Perl packages are very much like a Gentoo system, certain versions of packages work only with certain version of Perl and certain supporting packages only work with certain versions of packages. For example, the DBI package and its supporting package DBD::Oracle has dependencies:

http://cpansearch.perl.org/src/PYTHIAN/ ... /Oracle.pm requires DBI 1.51:

use DBI 1.51;

whereas a predeccessoar required DBI 1.28.
http://cpansearch.perl.org/src/PYTHIAN/ ... akefile.PL

use DBI 1.28;

so even within Perl, you have dependencies and cannot necessarily mix packages and subpackages with various versions of Perl.

Consequentely, within Gentoo, you have a package management system that has to manage another software's package management system. What seems precarious is that Gentoo is attempting to solve Perl's package management system by having Gentoo builds of the packages, e.g. dev-perl/DBD-Pg [PostgreSQL -- noteworthy is the perl pacakge DBD::Oracle is not available through Gentoo's portage system]. Another point is that some perl packages (there are over 15,000 of them) are supported, e.g. the DBI driver for PostgreSQL, and others not, i.e. the DBI driver for Oracle. I can see having packages in Gentoo which configure or deal with dependencies of Perl packages, and I'm wondering where the policy design for this may be documented anywhere. Perl has its own pacakge managment system, CPAN, and I'm wondering why Gentoo doesn't rely on that.

[khayyam]

Is there an explanation somewhere as to the design of handling Perl and it's packages within Gentoo?

jlpoole ... dilfridge (Andreas K. Hüttel ... of the perl herd) made the following recent posts on Planet Gentoo ...

Perl in Gentoo: dev-lang/perl, virtuals, and perl-core packages
Perl in Gentoo: Upgrading pains, perl-cleaner, and EAPI=5

Consequentely, within Gentoo, you have a package management system that has to manage another software's package management system. What seems precarious is that Gentoo is attempting to solve Perl's package management system by having Gentoo builds of the packages, e.g. dev-perl/DBD-Pg [PostgreSQL -- noteworthy is the perl pacakge DBD::Oracle is not available through Gentoo's portage system]. Another point is that some perl packages (there are over 15,000 of them) are supported, e.g. the DBI driver for PostgreSQL, and others not, i.e. the DBI driver for Oracle. I can see having packages in Gentoo which configure or deal with dependencies of Perl packages, and I'm wondering where the policy design for this may be documented anywhere. Perl has its own pacakge managment system, CPAN, and I'm wondering why Gentoo doesn't rely on that.

I wouldn't call CPAN a package manager, its an archive and (wrt, perl-core/CPAN) a build system. Its unfortunate IMO that a programming language (and modules written in that programming language) has taken on the task of "management" as this to me is the remit of the particular OS this software is installed on and not visa-versa. The outcome of such a model is that you end up with a methodology for each "package" (ie, perl-modules, ruby-gems, etc, etc) each of which requires additional duplication when it comes to the "package manager". Lets say I have a perl script with the following 'use MIME::Parser; use HTML::Parser; use Getopt::Std;' there is nothing in the install procedure to check that the API provided by these modules is going to be the same API as when this script was written, and as far as modules are concerned any API change triggering a >= requirement is not going to cover other modules whos requirements are not similar because there is no check done on the requirements of the currently installed packages, only that of the package being built. These dependencies are also not checked when perl itself is bumped because the modules are secondary and as they are installed to /usr/lib/perl{major_version}/vendor_perl/{version} are left to whatever mechanism is used to point the script to the "system perl". All this being the case (and forgive my above simplification of the issues involved) "management" is left to some other mechanism (namely whatever the OS provides, or via manual intervention).

best ... khay

[kernelOfTruth]

All or the most of these steps didn't help it to merge to success and thus bring to fruition


I'd simply go for the extreme approach (axe 'em all )

Code: Select all

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 127) virtual/perl-Version-Requirements-0.101.21...

well, that's quite a bunch - no wonder that it takes ages and were kind of gridlocked

Code: Select all

emerge --unmerge virtual/perl* dev-perl/*

Then re-emerge all the things with new flags and dependencies


Well, again late to the party


that shows that I haven't updated my system for quite some time + doing the abi_x86_32 switch NOW



edit:


is it just me or is portage really getting dumber and dumber ?

[ebuild U ] dev-lang/perl-5.22.0 [5.20.1-r2]
[ebuild N ] virtual/perl-File-Temp-0.230.400-r3
[ebuild N ] virtual/perl-Data-Dumper-2.158.0
[ebuild N ] dev-perl/extutils-pkgconfig-1.150.0

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

(dev-lang/perl-5.22.0:0/5.22::gentoo, ebuild scheduled for merge) pulled in by
=dev-lang/perl-5.22* required by (virtual/perl-Data-Dumper-2.158.0:0/0::gentoo, ebuild scheduled for merge)
^ ^^^^^
dev-lang/perl (Argument)

(dev-lang/perl-5.20.1-r2:0/5.20::gentoo, installed) pulled in by
dev-lang/perl:0/5.20=[-build(-)] required by (net-print/foomatic-db-engine-4.0.12:0/0::gentoo, installed)
^^^^^^^^
(and 5 more with the same problem)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

so I have to unmerge net-print/foomatic-db-engine

and run the command again


for the remaining 4 packages

[franzf]

Yay, stuck there too. But for me it's not just perl but also boost. Solving blockers for both packages is quite hard.
Furthermore I have to run emerge several times because portage simply doesn't give me all blocking packages. It currently takes several minutes to finish one emerge -uDNavt @world, only to see that there are more and more blockers. I really hate this, and I absolutely don't have the time to spend hours and hours to manually fix those issues. Probably it's time to finally get to a binary distribution :/ because this isn't the first time I hit such issues...

[geki]

well, here I am having dev-lang/perl-5.22.0 to emerge. o what fun - subslot hell.
command below is close to success, though I guess perl-cleaner needs some fixing. it misses some virtuals. or did I miss another flag?!

Code: Select all

perl-cleaner --reallyall -p -- dev-lang/perl:0

so I guess to unmerge perl virtuals may help; have to test, though.

wrt to boost I recommend my overlay; see my sig.
have boost slotted for easy upgrade paths - who wants to trigger libreoffice rebuilds is not your friend.
you may check its use flags to build necessary libraries!

[geki]

these commands got me very close to success:

Code: Select all

# mkdir -p /etc/portage/sets
# equery list -f --format="\$category/\$name" 'virtual/perl-*' > /etc/portage/sets/perl-virtuals
# emerge -p --unmerge @perl-virtuals # remove '-p' whenever you are ready
# perl-cleaner --reallyall -p -- dev-lang/perl:0

having these errors:

Code: Select all

[blocks B      ] <perl-core/Data-Dumper-2.158.0 ("<perl-core/Data-Dumper-2.158.0" is blocking virtual/perl-Data-Dumper-2.158.0)
[blocks B      ] <perl-core/ExtUtils-MakeMaker-7.40.100_rc ("<perl-core/ExtUtils-MakeMaker-7.40.100_rc" is blocking virtual/perl-ExtUtils-MakeMaker-7.40.100_rc)
[blocks B      ] <perl-core/libnet-3.50.0 ("<perl-core/libnet-3.50.0" is blocking virtual/perl-libnet-3.50.0)
...
  (perl-core/ExtUtils-MakeMaker-7.40.0-r1:0/0::gentoo, ebuild scheduled for merge) pulled in by
    perl-core/ExtUtils-MakeMaker:0

  (perl-core/libnet-1.270.0:0/0::gentoo, ebuild scheduled for merge) pulled in by
    perl-core/libnet:0

  (perl-core/Data-Dumper-2.154.0:0/0::gentoo, ebuild scheduled for merge) pulled in by
    perl-core/Data-Dumper:0

portage tree is not up to date, eh?!

Code: Select all

# equery list -p -o perl-core/ExtUtils-MakeMaker
 * Searching for ExtUtils-MakeMaker in perl-core ...
[IP-] [  ] perl-core/ExtUtils-MakeMaker-7.40.0-r1:0
# equery list -p -o perl-core/libnet
 * Searching for libnet in perl-core ...
[IP-] [  ] perl-core/libnet-1.270.0:0
# equery list -p -o perl-core/Data-Dumper
 * Searching for Data-Dumper in perl-core ...
[IP-] [  ] perl-core/Data-Dumper-2.154.0:0

well, anyone interested in a bugreport?!

edit #1
a ha, these virtuals should pull perl 5.22. fun. so, one may just remove the hard blockers and may be enlightened.
this could be tested by developers not arch testers.

Code: Select all

 * If you have just updated your major Perl version (e.g. from 5.20.2 to 5.22.0),

funny text of perl-cleaner.

... hell, it starts merging ...

edit #2
done - and there is another goodie I cannot resist

Code: Select all

 * It seems like perl-cleaner had to rebuild some packages.
 *
 * If you have just updated your major Perl version (e.g. from 5.20.2 to 5.22.0),
 * and have run perl-cleaner _after_ that update, then this means most likely
 * that these packages are buggy. Please file a bug on http://bugs.gentoo.org/ and
 * report that perl-cleaner needed to reinstall the following list:
 *    perl-core/Encode:0 perl-core/File-Temp:0 perl-core/CPAN-Meta:0 perl-core/ExtUtils-Manifest:0 dev-perl/Encode-Locale:0 dev-perl/DBI:0 dev-perl/HTML-Tagset:0 dev-perl/Data-OptList:0 dev-perl/WWW-RobotRules:0 dev-perl/Email-Address:0 dev-perl/HTTP-Negotiate:0 dev-perl/DateTime:0 dev-perl/Sub-Exporter:0 dev-perl/JSON-XS:0 dev-perl/Test-Deep:0 dev-perl/Module-Runtime:0 dev-perl/Email-Date-Format:0 dev-perl/HTTP-Daemon:0 dev-perl/Email-Abstract:0 dev-perl/PlRPC:0 dev-perl/HTTP-Cookies:0 dev-perl/MRO-Compat:0 dev-perl/IO-HTML:0 dev-perl/List-MoreUtils:0 dev-perl/LWP-MediaTypes:0 dev-perl/Dist-CheckConflicts:0 dev-perl/Params-Util:0 dev-perl/File-Listing:0 dev-perl/URI:0 dev-perl/Package-Stash:0 dev-perl/Module-Build:0 dev-perl/List-AllUtils:0 dev-perl/Package-DeprecationManager:0 dev-perl/Return-Value:0 dev-perl/HTTP-Message:0 dev-perl/Try-Tiny:0 dev-perl/Module-Pluggable:0 dev-perl/DateTime-TimeZone:0 dev-perl/Email-Simple:0 dev-perl/Types-Serialiser:0 dev-perl/Sys-SigAction:0 dev-perl/common-sense:0 dev-perl/Sub-Install:0 dev-perl/Net-HTTP:0 dev-perl/libwww-perl:0 dev-perl/Email-Send:0 dev-perl/Net-Daemon:0 dev-perl/IO-Socket-SSL:0 dev-perl/LWP-Protocol-https:0 dev-perl/Net-SSLeay:0 dev-perl/Module-Implementation:0 dev-perl/Class-Load:0 dev-perl/Unicode-EastAsianWidth:0 dev-perl/Params-Validate:0 dev-perl/Exporter-Tiny:0 dev-perl/HTML-Parser:0 dev-perl/HTTP-Date:0 dev-perl/libintl-perl:0 dev-perl/DBD-mysql:0 dev-perl/DateTime-Locale:0 dev-perl/Text-Unidecode:0 dev-perl/Package-Stash-XS:0 dev-perl/Class-Singleton:0

it talks for itself.

[geki]

well, here are my instructions how to upgrade perl w/subslot:=hell

Code: Select all

#!/bin/bash

# unmerge perl virtuals
emerge --unmerge $(qlist --installed virtual/perl)

# print perl blockers and quit
if emerge -pq dev-lang/perl:0 2>/dev/null | grep blocks
then
        echo
        echo "unmerge packages blocking perl upgrade"

        exit 1
else
        # upgrade perl
        perl-cleaner --reallyall -- dev-lang/perl:0
fi

exit 0

have fun

edit #2
updated my perl upgrade script

[steveL]

I don't understand why you're doing perl as part of the cleaner?

So far, I've found it better to do perl on its own (with -O or --nodeps), then the virtuals and pkgconfig, then the cleaner run, which usually needs the other stuff done first.

Then again, I'm not at this upgrade yet, so by all means tell me more.. ;-)

[muhsinzubeir]

All or the most of these steps didn't help it to merge to success and thus bring to fruition


I'd simply go for the extreme approach (axe 'em all )

Code: Select all

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 5 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 5 4 3 2 1
>>> Unmerging (1 of 127) virtual/perl-Version-Requirements-0.101.21...

well, that's quite a bunch - no wonder that it takes ages and were kind of gridlocked

Code: Select all

emerge --unmerge virtual/perl* dev-perl/*

Then re-emerge all the things with new flags and dependencies


Well, again late to the party


that shows that I haven't updated my system for quite some time + doing the abi_x86_32 switch NOW



edit:


is it just me or is portage really getting dumber and dumber ?

[ebuild U ] dev-lang/perl-5.22.0 [5.20.1-r2]
[ebuild N ] virtual/perl-File-Temp-0.230.400-r3
[ebuild N ] virtual/perl-Data-Dumper-2.158.0
[ebuild N ] dev-perl/extutils-pkgconfig-1.150.0

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

dev-lang/perl:0

(dev-lang/perl-5.22.0:0/5.22::gentoo, ebuild scheduled for merge) pulled in by
=dev-lang/perl-5.22* required by (virtual/perl-Data-Dumper-2.158.0:0/0::gentoo, ebuild scheduled for merge)
^ ^^^^^
dev-lang/perl (Argument)

(dev-lang/perl-5.20.1-r2:0/5.20::gentoo, installed) pulled in by
dev-lang/perl:0/5.20=[-build(-)] required by (net-print/foomatic-db-engine-4.0.12:0/0::gentoo, installed)
^^^^^^^^
(and 5 more with the same problem)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously. If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously. You may want to try a larger value of
the --backtrack option, such as --backtrack=30, in order to see if
that will solve this conflict automatically.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.

so I have to unmerge net-print/foomatic-db-engine

and run the command again


for the remaining 4 packages

Gooing through the same thing here ... unmerge bunch packages to get around this one....

P:S
Unmerging bunch perl stuffs does the trick ...

[geki]

woa, somehow missed the answer.

I don't understand why you're doing perl as part of the cleaner?

well, simply be done and be happy. feel free to do otherwise. I just like it short and simple and future proof if possible.

1. unmerge all your perl virtuals via portage set
2. (re)merge perl, all your perl packages and virtuals via perl-cleaner

[honp]

Thanks, it worked and helped...

[steveL]

I don't understand why you're doing perl as part of the cleaner?

well, simply be done and be happy. feel free to do otherwise. I just like it short and simple and future proof if possible. :)

Sure OK, I see what you're saying.

1. unmerge all your perl virtuals via portage set
2. (re)merge perl, all your perl packages and virtuals via perl-cleaner

Might as well do 1. with:

Code: Select all

emerge -cq $(qlist -IC virtual/perl)

since there's no real need to keep the set.

[geki]

steveL
thank you, updated my script!

the last missing piece would be to print the hard blocking packages without emerge noise.
though, did not find the proper emerge options. maybe there is some portage api?!

edit #1
updated my perl upgrade script wrt blockers - see my post above from Sat Aug 01, 2015