| View previous topic :: View next topic |
| Author |
Message |
honp
Guru
Joined: 25 Sep 2006
Posts: 355
Location: Good old Prague, Czech rep.
|
 Posted: Wed Jun 29, 2016 1:37 pm Post subject: [Solved] Perl 5.22 to perl-5.24 update |
 |
|
Hi all, for some time i had problem to update perl-5.22 to perl-5.24. Plenty of unresolvable dependencies, perl-cleaner didn't work (of course it didn't) and when i have found really easy step to solve it, i would like to share for others like me:)
dependency problems:
| Code: | emerge --with-bdeps=y --backtrack=1000 perl -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] dev-lang/perl-5.22.2:0/5.22::gentoo USE="berkdb gdbm -debug -doc -ithreads" 0 KiB
Total: 1 package (1 reinstall), Size of downloads: 0 KiB
WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:
dev-lang/perl:0
(dev-lang/perl-5.24.0-r1:0/5.24::gentoo, ebuild scheduled for merge) conflicts with
dev-lang/perl:0/5.22= required by (dev-perl/Test-Pod-Coverage-1.100.0:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.22=[-build(-)] required by (dev-vcs/git-2.9.0:0/0::gentoo, installed)
^^^^^^^^
=dev-lang/perl-5.22* required by (virtual/perl-Pod-Simple-3.290.0:0/0::gentoo, installed)
^ ^^^^^
dev-lang/perl:0/5.22=[-build(-)] required by (dev-perl/LWP-Protocol-https-6.60.0:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.22=[-build(-)] required by (dev-perl/XML-SAX-Base-1.80.0-r1:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.22=[-build(-)] required by (dev-perl/XML-SAX-0.990.0-r1:0/0::gentoo, installed)
^^^^^^^^
=dev-lang/perl-5.22* required by (virtual/perl-Digest-MD5-2.540.0:0/0::gentoo, installed)
^ ^^^^^
=dev-lang/perl-5.22* required by (virtual/perl-XSLoader-0.200.0:0/0::gentoo, installed)
^ ^^^^^
dev-lang/perl:0/5.22= required by (dev-perl/Sub-Name-0.150.0:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.22= required by (dev-vcs/subversion-1.9.4:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.22=[-build(-)] required by (dev-perl/File-BaseDir-0.30.0-r1:0/0::gentoo, installed)
...
|
so i used (for once:) ) emerge --nodep parametr, compiled perl 2.24, perl-cleaner --all, then was emerge able to update rest.
| Code: | emerge --with-bdeps=y --backtrack=1000 --nodeps perl
...
perl-cleaner --all
...
|
|
|
| Back to top |
|
 |
segmentation-fault
Tux's lil' helper
Joined: 11 Oct 2016
Posts: 99
|
| Posted: Tue Oct 11, 2016 1:47 pm Post subject: |
|
|
Sorry, but you are simplifying your life without good reason! 
That's not the way to do it. Just because dependencies give us headaches, we are not supposed to disable dependency calculations with --nodeps. If it were so, then why don't you use --nodeps always? You would be building a fine system then!
The right way to update Perl is:
- Delete all perl-core/* packages from the world file:
| Code: | | emerge --deselect --ask $(qlist -IC 'perl-core/*') |
Upgrade some important packages, if they are not up-to-date (check with eix):
| Code: | | emerge app-admin/perl-cleaner app-portage/perl-info |
Run:
| Code: | | emerge --tree --verbose --verbose-conflicts --oneshot dev-lang/perl $(qlist -IC 'virtual/perl-*') $(qlist -IC 'dev-perl/*') |
Most probably, this will fail with conflicts. Copy all packages that appear in those conflicts into your 'emerge' command, e.g.:
| Code: | emerge --tree --verbose --verbose-conflicts --oneshot dev-lang/perl $(qlist -IC 'virtual/perl-*') $(qlist -IC 'dev-perl/*') \
media-gfx/imagemagick \
dev-vcs/subversion \
app-backup/amanda \
sys-process/parallel \
net-libs/libproxy \
net-analyzer/rrdtool \
app-pda/pilot-link \
media-libs/ming \
media-gfx/graphite2 \
app-arch/rpm \
app-backup/amanda \
kde-base/perlqt \
app-editors/vim \
kde-base/perlkde \
dev-vcs/git \
sci-libs/gdal \
app-text/po4a \
net-print/cups-filters \
games-arcade/frozen-bubble \
mail-filter/spamassassin \
media-libs/exiftool \
www-apache/mod_perl \
media-gfx/graphviz \
sys-apps/texinfo \
perl-core/File-Temp \
app-editors/gvim \
net-analyzer/net-snmp \
|
(where I had to use '\' at the end of each line to be able to continue the command to the next line - you may put them all on one line).
Run perl-cleaner:
Since we didn't use any deep dependencies (I have noticed that --oneshot does not give me the expected behaviour when I use --deep --with-bdeps=y), you will probably have to update swig, if you have it installed:
It's painful, but right... |
|
| Back to top |
|
|
segmentation-fault
Tux's lil' helper
Joined: 11 Oct 2016
Posts: 99
|
| Posted: Tue Oct 11, 2016 4:07 pm Post subject: |
|
|
Let me clarify step three above. What is so special about this list of packages that emerge complains about when we run
| Code: | | emerge --tree --verbose --verbose-conflicts --oneshot dev-lang/perl $(qlist -IC 'virtual/perl-*') $(qlist -IC 'dev-perl/*') |
and why do we have to run this command once to find it out - isn't there a better way?
I made an experiment: I computed the difference between the output of
| Code: | | qdepends -CQ dev-lang/perl | xargs -n 1 qatom | cut -d ' ' -f 1-2 | tr ' ' '/' | sort | uniq |
and
| Code: | | cat XXX | sort | uniq |
where XXX was a file containing the above list
| Code: | app-arch/rpm
app-backup/amanda
app-editors/gvim
app-editors/vim
app-pda/pilot-link
app-text/po4a
dev-vcs/git
dev-vcs/subversion
games-arcade/frozen-bubble
kde-base/perlkde
kde-base/perlqt
mail-filter/spamassassin
media-gfx/graphite2
media-gfx/graphviz
media-gfx/imagemagick
media-libs/exiftool
media-libs/ming
net-analyzer/net-snmp
net-analyzer/rrdtool
net-libs/libproxy
net-print/cups-filters
perl-core/File-Temp
sci-libs/gdal
sys-apps/texinfo
sys-process/parallel
www-apache/mod_perl |
Then I had a look into the DEPEND variables of the ebuilds in that difference list. What I saw is this:
Portage complains NOT about ALL installed packages that just somehow 'depend' on dev-lang/perl (i.e. it does NOT complain about ALL packages in the output of qdepends above), but only about the subset that does NOT contain dev-lang/perl in the RDEPEND variable of the ebuild. That is, it complains about a subset of packages that depend on Perl - those that depend on Perl, excluding those that depend on it only to run, at runtime!
That is, if we had a command that outputs all packages that depend on X, but not at runtime only (i.e. they depend on X at compile-time, or for some other reason, but not for running only), then we could replace the above kind-of-hard-coded list of packages with the output of that command for dev-lang/perl - but I just can't find one...
If you just replace the above list with
| Code: | | qdepends -CQ dev-lang/perl | xargs -n 1 qatom | cut -d ' ' -f 1-2 | tr ' ' '/' |
i.e. if you try to make your life simple and just use:
| Code: | | emerge --tree --verbose --verbose-conflicts --oneshot dev-lang/perl $(qlist -IC 'virtual/perl-*') $(qlist -IC 'dev-perl/*') $(qdepends -CQ dev-lang/perl | xargs -n 1 qatom | cut -d ' ' -f 1-2 | tr ' ' '/') |
then you WILL update Perl, but the chosen set of packages to update on the command line will be total overkill - it will include all packages that depend on Perl, including those that depend on it only at runtime! These are too many!
 All this makes perfectly sense: if a package depends on Perl because it needs to run Perl at some point of its execution, then it 'depends on Perl' - but not in the sense that it must be recompiled when we update Perl. Therefore, these packages in the output of
| Code: | | qdepends -CQ dev-lang/perl | xargs -n 1 qatom | cut -d ' ' -f 1-2 | tr ' ' '/' |
can be safely ommitted from the emerge invocation. And the rest must be on the command, because it must be rebuilt - it needs Perl in a more fundamental way than just 'during runtime'. |
|
| Back to top |
|
|
segmentation-fault
Tux's lil' helper
Joined: 11 Oct 2016
Posts: 99
|
| Posted: Wed Oct 12, 2016 1:33 pm Post subject: |
|
|
To complete the picture, let me add some more details:
How to make the list of packages more manageable
To make things somewhat more manageable, one could create a 'custom set' - let's call it 'perl' - that will contain the names of the packages to be updated each time one want to update Perl:
| Code: | mkdir -p /etc/portage/sets
echo 'dev-lang/perl' > /etc/portage/sets/perl
qlist -IC 'virtual/perl-*' >> /etc/portage/sets/perl
qlist -IC 'dev-perl/*' >> /etc/portage/sets/perl
cat XXX >> /etc/portage/sets/perl |
where XXX is the file with the package names shown above (the packages that depend on Perl, excluding those that depend on it only at runtime). Then one could reduce the above monster command to a simple:
| Code: | | emerge --tree --verbose --verbose-conflicts --oneshot @perl |
HOWEVER...as simple as it looks, there are two caveats:
- 1. You will have to regenerate the perl set each time you install/uninstall
- a virtual/perl-* package
- a dev-perl/perl-* package
- a package that belongs to that 'XXX' set (you know: packages that depend on Perl, excluding those that depend on it only at runtime)
- 2. Don't expect to issue such a command (which, on my system will update 417 packages!) - and forget about it! It's not 'fire-and-forget'! See below why.
You can't expect to update Perl in one shot
At some point in the middle of the upgrade of 417 packages, at package 217, which happened to be dev-perl/GDTextUtil-0.860.0-r1, I was greeted with the error:
| Code: | * Using ExtUtils::MakeMaker
* perl Makefile.PL PREFIX=/usr INSTALLDIRS=vendor INSTALLMAN3DIR=none DESTDIR=/host/var/tmp/portage/dev-perl/GDTextUtil-0.860.0-r1/image/
GD.c: loadable library and perl binaries are mismatched (got handshake key 0x7dc0080, needed 0x7ec0080)
* ERROR: dev-perl/GDTextUtil-0.860.0-r1::gentoo failed (configure phase):
* Unable to build! |
which means it was time to run
| Code: | | emerge @preserved-rebuild |
...but that got interrupted too, at www-apache/mod_perl-2.0.10_pre201601, with the error:
| Code: | Can't locate Apache/TestConfig.pm in @INC (you may need to install the Apache::TestConfig module) (@INC contains: lib /etc/perl /usr/local/lib/perl5/5.22.2/i686-linux-thread-multi /usr/local/lib/perl5/5.22.2 /usr/lib/perl5/vendor_perl/5.22.2/i686-linux-thread-multi /usr/lib/perl5/vendor_perl/5.22.2 /usr/local/lib/perl5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.22.2/i686-linux-thread-multi /usr/lib/perl5/5.22.2 .) at lib/ModPerl/Code.pm line 28.
BEGIN failed--compilation aborted at lib/ModPerl/Code.pm line 28.
Compilation failed in require at lib/Apache2/Build.pm line 86.
BEGIN failed--compilation aborted at lib/Apache2/Build.pm line 86.
Compilation failed in require at Makefile.PL line 38.
BEGIN failed--compilation aborted at Makefile.PL line 38.
|
Reason
Apache needs to be rebuilt due to a necessary
| Code: | | emerge @revdep-rebuild |
that MUST run before we continue with the original emerge (which was trying to upgrade Perl...). Due to the fact that Perl IS upgraded, but only part of its modules are recompiled, the necessary .pm file
/usr/lib/perl5/vendor_perl/5.20.2/Apache/TestConfig.pm
is available only for Perl 5.20.2 and not for the shiny new one 5.22.2!
Solution
We must interrupt the interruption and re-merge dev-perl/Apache-Test, which owns the above TestConfig.pm:
| Code: | | emerge -1u dev-perl/Apache-Test |
Only thereafter can we continue with
| Code: | | emerge @revdep-rebuild |
and then with
Now...guess what...
...after so many interruptions, 'emerge --resume' will not work anymore! emerge remembers up to two interrupted runs, so if you had to emerge and interrupt and emerge and interupt and emerge and interrupt (due to errors, for example, as above)...then you are out of luck, your 417 packages are gone! 
So now you stay in front of a dilemma: rerun 'emerge -1' to re-merge ALL 417 packages (i.e. redo the merging of the first 216 in the list and waste yet another day), or run 'emerge -1u', running the risk of NOT remerging those packages whose versions have not changed (which is NOT what you want, you want to re-merge ALL perl-related packages, but NOT the 216 you have already merged and emerge has forgotten about). What do you choose?
I chose to create a list of all installed packages on my system with:
| Code: | | eix '-I*' --format '<installedversions:DATESORT>' | sort -n | cut -f2-3 > eix-installed |
then open eix-installed and delete all lines above
| Code: | | 10/11/2016 03:05:18 PM dev-lang/perl |
The remaining lines will contain the packages I DON'T want to re-merge. Get rid of the date and time stamps with:
| Code: | | awk `{print $4}` eix-installed > eix-exclude |
Put all packages on one line (in vi with: Shift+J) and use that huge line
as a parameter to the --exclude option to emerge:
| Code: | | emerge --tree --verbose --verbose-conflicts --oneshot --exclude 'huge list here' @perl |
Want to see it? Here it is:
| Code: | | emerge --tree --verbose --verbose-conflicts --oneshot --exclude 'dev-lang/perl virtual/perl-File-Spec virtual/perl-Scalar-List-Utils virtual/perl-Storable virtual/perl-Test-Harness virtual/perl-Sys-Syslog dev-perl/Net-Daemon dev-perl/PlRPC dev-perl/libintl-perl perl-core/File-Temp virtual/perl-File-Temp virtual/perl-ExtUtils-MakeMaker dev-perl/DBI dev-perl/Text-Unidecode dev-perl/Unicode-EastAsianWidth virtual/perl-Carp dev-perl/XML-Parser virtual/perl-Exporter virtual/perl-MIME-Base64 virtual/perl-Digest-MD5 virtual/perl-IO virtual/perl-ExtUtils-CBuilder dev-perl/extutils-pkgconfig virtual/perl-Getopt-Long virtual/perl-version dev-perl/File-Which virtual/perl-ExtUtils-ParseXS virtual/perl-File-Path virtual/perl-XSLoader virtual/perl-parent dev-perl/URI dev-perl/Params-Util virtual/perl-Compress-Raw-Zlib virtual/perl-Digest-SHA virtual/perl-Parse-CPAN-Meta virtual/perl-Time-HiRes virtual/perl-if dev-perl/Crypt-DES dev-perl/Digest-HMAC dev-perl/TermReadKey dev-perl/XML-NamespaceSupport dev-perl/XML-XPath virtual/perl-Text-ParseWords dev-perl/Archive-Zip dev-perl/Authen-SASL dev-perl/Crypt-Blowfish dev-perl/File-HomeDir dev-perl/IO-String dev-perl/LWP-MediaTypes dev-perl/Socket6 dev-perl/Sub-Install dev-perl/Data-OptList dev-perl/Sub-Exporter dev-perl/Sub-Name dev-perl/Try-Tiny dev-perl/libxml-perl virtual/perl-Archive-Tar virtual/perl-CPAN-Meta-YAML virtual/perl-ExtUtils-Install virtual/perl-IPC-Cmd virtual/perl-JSON-PP virtual/perl-CPAN-Meta virtual/perl-Module-Metadata virtual/perl-Perl-OSType virtual/perl-Pod-Parser virtual/perl-Time-Local dev-perl/HTTP-Date dev-perl/Capture-Tiny dev-perl/Class-Data-Inheritable dev-perl/Class-Inspector dev-perl/File-ShareDir dev-perl/Class-Loader dev-perl/Class-XPath dev-perl/Clone dev-perl/Convert-ASN1 dev-perl/Crypt-CBC dev-perl/Data-Buffer dev-perl/Encode-Locale dev-perl/HTML-Tagset dev-perl/HTML-Parser dev-perl/IO-stringy dev-perl/JSON dev-perl/NetAddr-IP dev-perl/OLE-StorageLite dev-perl/Package-Stash-XS dev-perl/Perl-Tidy dev-perl/SVG dev-perl/Sort-Versions dev-perl/Sub-Uplevel dev-perl/TimeDate dev-perl/Tk virtual/perl-Compress-Raw-Bzip2 virtual/perl-IO-Compress virtual/perl-DB_File virtual/perl-Devel-PPPort virtual/perl-Digest dev-perl/Digest-SHA1 virtual/perl-ExtUtils-Manifest virtual/perl-IO-Zlib virtual/perl-Locale-Maketext dev-perl/Locale-Maketext-Lexicon virtual/perl-Locale-Maketext-Simple virtual/perl-Module-CoreList virtual/perl-Module-Load virtual/perl-Module-Load-Conditional virtual/perl-Params-Check virtual/perl-Pod-Escapes virtual/perl-Text-Balanced virtual/perl-Text-Tabs+Wrap virtual/perl-Time-Piece virtual/perl-autodie dev-perl/Algorithm-Diff dev-perl/Text-Diff dev-perl/AppConfig dev-perl/Archive-Extract dev-perl/Array-RefElem dev-perl/B-Keywords dev-perl/Class-Accessor dev-perl/Class-MethodMaker dev-perl/Class-Singleton dev-perl/Compress-Bzip2 dev-perl/Config-Tiny dev-perl/Convert-ASCII-Armour dev-perl/Crypt-DES_EDE3 dev-perl/Crypt-IDEA dev-perl/Crypt-OpenSSL-Bignum dev-perl/Crypt-OpenSSL-Random dev-perl/Crypt-OpenSSL-RSA dev-perl/Crypt-RC4 dev-perl/Devel-Size dev-perl/Devel-StackTrace dev-perl/Exception-Class dev-perl/Digest-BubbleBabble dev-perl/Digest-MD2 dev-perl/Digest-Perl-MD5 dev-perl/Email-Address dev-perl/Email-Date-Format dev-perl/Exporter-Tiny dev-perl/List-MoreUtils dev-perl/Dist-CheckConflicts dev-perl/PPI dev-perl/ExtUtils-AutoInstall dev-perl/File-Listing dev-perl/File-Remove dev-perl/File-Slurp dev-perl/Geo-IP dev-perl/IO-Multiplex dev-perl/IO-Tty dev-perl/IPC-Run dev-perl/IPC-ShareLite dev-perl/IPC-System-Simple dev-perl/LWP-Authen-Wsse dev-perl/Linux-Pid dev-perl/List-AllUtils dev-perl/Log-Agent dev-perl/MIME-Charset dev-perl/MIME-Types dev-perl/MRO-Compat dev-perl/Math-GMP dev-perl/Module-ScanDeps dev-perl/Mozilla-CA dev-perl/Net-CIDR-Lite dev-perl/Net-Patricia dev-perl/Net-SSLeay dev-perl/IO-Socket-SSL dev-perl/Net-HTTP dev-perl/PadWalker dev-perl/Devel-Caller dev-perl/Devel-LexAlias dev-perl/Eval-Closure dev-perl/Parse-Yapp dev-perl/Pod-Spell dev-perl/SGMLSpm dev-perl/Set-Scalar dev-perl/Shell-EnvImporter dev-perl/String-CRC32 dev-perl/String-Format dev-perl/Sub-Exporter-Progressive dev-perl/Devel-GlobalDestruction dev-perl/Text-CSV_XS dev-perl/Text-CharWidth dev-perl/Text-Iconv dev-perl/Text-Patch dev-perl/Text-WrapI18N dev-perl/Tie-EncryptedHash dev-perl/Tie-Simple dev-perl/Tree-DAG_Node dev-perl/Unicode-Map dev-perl/WWW-RobotRules dev-perl/XML-DTDParser dev-perl/XML-Handler-YAWriter dev-perl/XML-NodeFilter dev-perl/XML-RegExp dev-perl/XML-SAX-Base dev-perl/XML-SAX dev-perl/XML-LibXML dev-perl/XML-Elemental dev-perl/XML-Simple dev-perl/XML-Filter-BufferText dev-perl/XML-SAX-Writer dev-perl/XML-LibXML-Iterator dev-perl/XML-XPathEngine dev-perl/YAML dev-perl/PAR-Dist dev-perl/YAML-Tiny dev-perl/perl-ldap media-libs/ming virtual/perl-libnet dev-perl/MailTools dev-perl/MIME-Lite dev-perl/MIME-tools dev-perl/Net-SMTP-SSL virtual/perl-Test-Simple dev-perl/Test-Deep dev-perl/Test-Exception dev-perl/Test-Warn virtual/perl-Term-ANSIColor virtual/perl-Math-BigInt dev-perl/Crypt-DSA dev-perl/Math-BigInt-GMP virtual/perl-Data-Dumper dev-perl/Module-Build dev-perl/File-BaseDir dev-perl/File-DesktopEntry dev-perl/File-MimeInfo dev-perl/ExtUtils-Depends dev-perl/GD dev-perl/glib-perl dev-perl/Error dev-tcltk/tclperl sys-apps/texinfo app-editors/vim net-analyzer/net-snmp app-editors/gvim media-gfx/graphviz kde-base/perlqt net-nds/openldap dev-db/postgresql:9.5 kde-base/kdelibs dev-perl/Apache-Test www-apache/mod_perl kde-base/perlkde net-analyzer/nagios-core media-gfx/imagemagick media-gfx/uniconvertor app-office/gnumeric dev-php/pecl-imagick media-video/transcode sci-mathematics/octave media-gfx/inkscape' @perl |
Moral of the story: You can hide complexity, but you can't run away from it! 
PS: I would probably have a much more manageable 'huge list' to resume merging, if I had used --keep-going in my first try...or retried immediately with 'emerge --resume --skipfirst'... |
|
| Back to top |
|
|
segmentation-fault
Tux's lil' helper
Joined: 11 Oct 2016
Posts: 99
|
| Posted: Wed Oct 12, 2016 7:29 pm Post subject: |
|
|
The adventure 'update perl the right way' continues:
The above error from GD is a different kind of beast: it does NOT go away with a simple
| Code: | | emerge @revdep-rebuild |
nor with
| Code: | | emerge -1 media-libs/gd |
or re-merging anything that has 'GD' in its name for this matter - it is a bug and the only workararound is to unmask the next 'testing' version for it, see GDTextUtil could not be emerged with Perl 5.22.
Trying to resolve it in despair, I also typed the very same command I set forth to replace:
which practically recomputed the 100 or so remaining packages and initiated their re-merge - as if I had used 'emerge --resume'! Of course, the re-merge stopped at the same GD error above - but this effort demonstrated to me that I had come full circle:
Another moral of the story: If all your efforts to do it 'the right way' result in so many errors that at the end you resort to using the same tools you are trying to avoid - then maybe 'the right way' is simply impractical. Maybe it's better to break things first with '--nodeps', then let the right tool find and fix the chaos afterwards... |
|
| Back to top |
|
|
bschnzl
Tux's lil' helper
Joined: 13 Mar 2005
Posts: 94
|
| Posted: Thu Oct 13, 2016 3:49 am Post subject: |
|
|
Good Evening -
Another block updating PERL. I thought the new EAPI was supposed to stop this. Now I see an issue with 5.22 -> 5.24! My system is still on 5.20 (no ~amd64, no arch testing). I am getting the same run around!
Do we seriously need to dump perl and rebuild it? Seg'-fault lists why that is just a bad idea above.
I did this:
| Code: | | emerge perl --verbose-conflicts -Dvp > XXX 2>&1 |
That dumped the whole mess into a file called XXX. Then I did:
| Code: | | grep '5.20' XXX | awk '{print $4}' | sed 's/-[0-9].*$//' | sed 's/^.*\///' | less |
That gave a one column stack of the package atoms that were holding up portage.
I removed the newlines, copied the resulting string of package atoms into:
| Code: | | emerge perl HTTP-Cookies perl-IO-Compress perl-IO Test-Deep graphite2 Encode-Locale PlRPC libproxy XML-Parser perl-Exporter Net-HTTP cups-filters HTTP-Date IO-Socket-SSL vim perl-Digest-SHA perl-ExtUtils-CBuilder LWP-Protocol-https Module-Build URI perl-ExtUtils-ParseXS graphviz File-BaseDir DBI HTTP-Negotiate libintl-perl perl-Perl-OSType perl-Text-ParseWords perl-ExtUtils-Manifest Authen-SASL File-DesktopEntry IO-HTML Digest-HMAC perl-Digest-MD5 File-Temp File-MimeInfo xfconf perl-ExtUtils-Install Net-Daemon TermReadKey LWP-MediaTypes WWW-RobotRules perl-Compress-Raw-Bzip2 Archive-Zip HTTP-Daemon imagemagick perl-MIME-Base64 perl-parent libwww-perl texinfo Unicode-EastAsianWidth HTML-Parser HTTP-Message perl-Encode glib-perl libnet File-Listing perl-Carp HTML-Tagset Net-SSLeay perl-Compress-Raw-Zlib --backtrack=99 -Dvp |
The update is on (68 of 83).
It is brute force, but the update (errr, rebuild) is running cleanly! I did no @preserved, no eix, no complex portage commands. Evidently, those are fraught with error and risk of losing packages anyhow.
One would think this sort of thing would be caught by the arch testers. It is certainly not something that one would expect for a stable distro.
On the other hand, my headless server showed no sign of concern. It dual slotted perl just fine. We'll see how this goes when I get to my racks and try to rebuild around xen, mysql, etc. I may not have time to update this. Good Luck to All.
After the run, I did have to rebuild openldap and hexchat (on my primary lappy). I ran until clean, and resume the update.
_________________
Persistance Pays |
|
| Back to top |
|
|
segmentation-fault
Tux's lil' helper
Joined: 11 Oct 2016
Posts: 99
|
| Posted: Thu Oct 13, 2016 1:04 pm Post subject: |
|
|
| bschnzl wrote: |
I did no @preserved, no eix, no complex portage commands. Evidently, those are fraught with error and risk of losing packages anyhow.
One would think this sort of thing would be caught by the arch testers. It is certainly not something that one would expect for a stable distro.
|
No, none of the commands I showed to you above is erroneous or anything like that. The commands select some packages which I then pass to emerge. If you had as many packages as I do (400+ for perl), you would end up with the same huge lists of packages to pass to emerge as mine. And when you have a huge list to update, some package in the middle will require special attention (be it through some compilation error, library breakage, or similar) and you will have to stop, investigate, take your measures, rerun.
All this is because when you say
portage will update perl and its dependencies - but NOT its reverse dependencies, i.e. not the packages that depend on perl, only the packages that perl depends on. So if you have a perl module, say mod-X, that depends on perl-5.20 (because when you installed it you compiled it with the then current perl-5.20) and you upgrade to perl-5.22 with the command above (i.e. without putting also mod-X on the emerge invocation), you will get "perl-5.22 is blocking mod-X" error, which I personally always read the other way round: "mod-X is blocking your newcomer perl-5.22").
Your task becomes then to find all such packages and put them on the emerge command, together with perl. This is easy if instead of perl you upgrade some other package which does not have too many such reverse dependencies. But in the case of perl, boost, kde, qt etc. the task is a formidable one, as you have seen above. That's why most people either give up and run "emerge @world", or "emerge --nodeps" (and then try to collect the pieces with tools like perl-cleaner in our case) - or let emerge find the blockers, fish them out of its output and put them on the command next time, as you did. But background is the same: one has to find the missing packages and put them on the same emerge command together with the package one is trying to update.
It would be so nice if one could say "emerge perl and all its baggage", "emerge boost and all its reverse dependencies and such", "emerge all my KDE" without having to resort to
| Code: | | emerge XXXXXX $(qdepends -CQ XXXXXX | xargs -n 1 qatom | cut -d ' ' -f 1-2 | tr ' ' '/') |
and other hackisms, which may or may not catch all required packages...
It would be so nice if the system would maintain not only the 'system' and 'world' files, but also 'perl', 'boost', 'kde', 'gnome', 'qt', 'x11' and possibly other sets, so that one would not have to choose between 0 and 1 only (i.e. system and world sets). It would be so convenient to be able to upgrade perl with just
for a system-maintained perl set. But I am dreaming...  |
|
| Back to top |
|
|
segmentation-fault
Tux's lil' helper
Joined: 11 Oct 2016
Posts: 99
|
| Posted: Thu Oct 13, 2016 1:19 pm Post subject: |
|
|
Oh...and I forgot my favourite set: icu! 
It's OT, but...just try to upgrade icu without issuing 'emerge ... @world'.
I did it - and the PITA was three times that of perl... |
|
| Back to top |
|
|
bschnzl
Tux's lil' helper
Joined: 13 Mar 2005
Posts: 94
|
| Posted: Thu Oct 13, 2016 11:53 pm Post subject: |
|
|
The reason I posted was that @system stopped, at invocation, because it could not work out the dependencies...
I appreciate your post and expertise. I wanted to give it a bump - and contribute my own experience.
Perhaps all distro's deal with dependencies, forward and reverse. This is just a report, with no advancement of the technology. If it helps our fellow travellers, that is enough.
B.
_________________
Persistance Pays |
|
| Back to top |
|
|
direwolf
Tux's lil' helper
Joined: 11 Jun 2003
Posts: 125
Location: Richmond, VA
|
| Posted: Mon Nov 28, 2016 12:03 am Post subject: |
|
|
| segmentation-fault wrote: | Sorry, but you are simplifying your life without good reason!
That's not the way to do it. Just because dependencies give us headaches, we are not supposed to disable dependency calculations with --nodeps. If it were so, then why don't you use --nodeps always? You would be building a fine system then!
The right way to update Perl is:
[list]
[*]Delete all perl-core/* packages from the world file:
| Code: | | emerge --deselect --ask $(qlist -IC 'perl-core/*') |
[*]Upgrade some important packages, if they are not up-to-date (check with eix):
| Code: | | emerge app-admin/perl-cleaner app-portage/perl-info |
|
This is a crazy way to have to update ... anything.
I tried this since it seems to work for some folks, but not for me. The first step above found nothing to remove, and the second step just gave me the same errors:
| Code: | Calculating dependencies... done!
[ebuild R ] app-admin/perl-cleaner-2.20
[ebuild N ] dev-perl/Class-MethodMaker-2.240.0
[ebuild U ] dev-lang/perl-5.22.2 [5.20.2]
[ebuild N ] dev-perl/Shell-EnvImporter-1.70.0-r2
[ebuild N ] virtual/perl-Term-ANSIColor-4.30.0-r1
[ebuild N ] dev-perl/PortageXS-0.02.10-r4 USE="-minimal"
[ebuild N ] app-portage/perl-info-0.16
!!! 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.20.2:0/5.20::gentoo, installed) pulled in by
dev-lang/perl:0/5.20=[-build(-)] required by (dev-perl/Sub-Uplevel-0.250.0:0/0::gentoo, installed)
^^^^^^^^
=dev-lang/perl-5.20* required by (virtual/perl-MIME-Base64-3.140.0-r1:0/0::gentoo, installed)
^ ^^^^^
(and 134 more with the same problems)
(dev-lang/perl-5.22.2:0/5.22::gentoo, ebuild scheduled for merge) pulled in by
=dev-lang/perl-5.22* required by (virtual/perl-version-0.990.900-r2:0/0::gentoo, installed)
^ ^^^^^
(and 11 more with the same problem)
|
_________________
========================================================
"Somebody has to do something, and it's just incredibly pathetic that it has to be us."
- Jerry Garcia |
|
| Back to top |
|
|
direwolf
Tux's lil' helper
Joined: 11 Jun 2003
Posts: 125
Location: Richmond, VA
|
| Posted: Mon Nov 28, 2016 12:32 am Post subject: Skip perl |
|
|
Well it seems this entire exercise is for naught, anyway. I have several packages that apparently require perl 5.20.
| Code: |
dev-lang/perl:0/5.20= required by (dev-python/subunit-1.2.0-r1:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20= required by (app-editors/vim-7.4.769:0/0::gentoo, installed)
^^^^^^^^
>=dev-lang/perl-5.8.8:0/5.20= required by (media-gfx/imagemagick-6.9.4.6:0/6.9.4.6::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20=[-build(-)] required by (dev-vcs/git-2.7.3-r1:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20= required by (sys-apps/texinfo-6.1:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20=[-build(-)] required by (perl-core/File-Temp-0.230.400-r1:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20= required by (net-libs/libproxy-0.4.13-r1:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20= required by (dev-vcs/subversion-1.9.4:0/0::gentoo, installed)
^^^^^^^^
dev-lang/perl:0/5.20= required by (net-print/cups-filters-1.5.0:0/0::gentoo, installed)
^^^^^^^^
|
So now I just have to manually update every package in @system without installing Perl or any update that depends on Perl 5.22. Fun times!
_________________
========================================================
"Somebody has to do something, and it's just incredibly pathetic that it has to be us."
- Jerry Garcia |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Mon Nov 28, 2016 8:52 am Post subject: Re: Skip perl |
|
|
| direwolf wrote: | | I have several packages that apparently require perl 5.20. |
No. You see this only because the dependy of these packages is dev-lang/perl:0= (or something similar), i.e. the installed version of these packages depends on perl 5.20; however, they will be just reemerged after the installation of perl, and then they depend on perl 5.24 (or whatever your installed version of perl at that time is). In a sense, you can consider this portage output as a "false positive", appearing only because portage is not able to resolve the true blocker. |
|
| Back to top |
|
|
direwolf
Tux's lil' helper
Joined: 11 Jun 2003
Posts: 125
Location: Richmond, VA
|
| Posted: Fri Jan 06, 2017 6:17 pm Post subject: Re: Skip perl |
|
|
| mv wrote: | | direwolf wrote: | | I have several packages that apparently require perl 5.20. |
No. You see this only because the dependy of these packages is dev-lang/perl:0= (or something similar), i.e. the installed version of these packages depends on perl 5.20; however, they will be just reemerged after the installation of perl, and then they depend on perl 5.24 (or whatever your installed version of perl at that time is). In a sense, you can consider this portage output as a "false positive", appearing only because portage is not able to resolve the true blocker. |
Thus, "apparently".
I'm using bschnzl's solution now, which appears to be working (at 32 of 136). I've just been skipping perl on updates until now, but I wanted to go ahead and get this done. bschnzl provided the most expedient solution, I think. I'll see what happens when it's done and I go though perl-cleaner and --depclean.
_________________
========================================================
"Somebody has to do something, and it's just incredibly pathetic that it has to be us."
- Jerry Garcia |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jan 07, 2017 9:05 am Post subject: Re: Skip perl |
|
|
| direwolf wrote: | | I'm using bschnzl's solution now |
So you actually didn't have any blocks, just portage couldn't resolve it. Then just increasing the --backtrack value should have done it. |
|
| Back to top |
|
|
mimosinnet
l33t
Joined: 10 Aug 2006
Posts: 713
Location: Barcelona, Spain
|
| Posted: Sat Jan 14, 2017 1:49 pm Post subject: |
|
|
| segmentation-fault wrote: | Sorry, but you are simplifying your life without good reason!
That's not the way to do it. Just because dependencies give us headaches, we are not supposed to disable dependency calculations with --nodeps. If it were so, then why don't you use --nodeps always? You would be building a fine system then! |
I have come across this post searching on how to solve perl dependencies. I have been unsuccessful at solving the dependencies using the right way and I have finally had success following honp suggestion  . As I understand it, what honp is suggesting is to emerge dev-lang/perl without dependencies and solve the dependencies after emerging it. Despite that it works, I do not see what is wrong in solving the dependencies after emerging dev-lang/perl.
Cheers!
_________________
Please add [solved] to the initial post's subject line if you feel your problem is resolved.
Take care of the community answering unanswered posts. |
|
| Back to top |
|
|
Decibels
Veteran
Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.
|
| Posted: Sun Apr 16, 2017 3:00 pm Post subject: |
|
|
So just rebuilt my system from scratch with latest stage3 in March. Had perl-5.22.3_rc4 and since system was pretty new didn't think I would run into problems with upgrade. But did! Ran into the same problems described here.
I tried honp method pretty much same way. Worked! Though if things didn't go good would have been another rebuild.
| Quote: | emerge --with-bdeps=y --backtrack=1000 --nodeps perl
perl-cleaner --all |
Then just to be sure I added:
| Code: | emerge --ask uND world
...
perl-cleaner --all
...
revdep-rebuild
... |
The 'world' did about 10 packages, perl-cleaner (2nd time) did 1 package, then revdep-rebuild only rebuilt openoffice-bin (which it always seems to do with the new revdep-rebuild).
Rebooted this morning and all seems good!!
_________________
Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Sun Apr 16, 2017 5:43 pm Post subject: |
|
|
To each, his/her own. But I find it easier and faster to just break it a bit by using -1 --nodeps to update perl first, since @world update will recompile all perl stuff after that. That will save you quite some time overall if you are running a not so new computer.
After that, just run your regular update and it will work.
The problem here is that, on each update, perl and its siblings inter-block each other, and portage, up to today, has no means to handle that other than silly backtrack, which might work provided you have enough patience, which I haven't. |
|
| Back to top |
|
|
ticho
Tux's lil' helper
Joined: 23 Oct 2003
Posts: 138
Location: yes
|
| Posted: Sun Apr 16, 2017 10:16 pm Post subject: |
|
|
Doesn't anyone see something wrong, on a deeper, systemic level, with Portage, if it requires users to do this kind of hacky surgery to their systems in order to perform a Perl upgrade? Or is it because of bad work done by the Perl team? (Are they still calling them herds? I've not been keeping youch for years now.)
It is really weird that one has to do this on a system using "stable" arch keyword.
_________________
The more you depend on forces outside yourself, the more you are dominated by them. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 8936
|
| Posted: Sun Apr 16, 2017 11:00 pm Post subject: |
|
|
| The current solution surely brings portage to its knees, but it ensures you have a consistent upgrade. You don't really want to go back to the days of relying on perl-cleaner. slot-operator-rebuilds need to be improved, maybe default backtrack value increased for a start. |
|
| Back to top |
|
|
jserink
Veteran
Joined: 30 Jan 2004
Posts: 1008
|
| Posted: Sun Apr 16, 2017 11:48 pm Post subject: |
|
|
And the reason there is no sys utility to do all this is?
If this nuclear physics procedure for updating perl is how this was PLANNED, this will end gentoo.
Its stuff like this that pisses off and scares newbees.
I'm all for technical knowledge on how my machine works, I want that, but for the casual Linux user, the Devs can't be serious.
While I seriously appreciate the work gone into to seg-fault sharing his notes, I look at the procedure and the only thing that comes to mind is "You can't be serious?".
Perl is an absolute requirement on the system and to have to go through a procedure that would scare most third year comp-sci students I think is a bit much.
Devs, this needs LOTS more thinking.
Cheers,
John |
|
| Back to top |
|
|
Decibels
Veteran
Joined: 16 Aug 2002
Posts: 1623
Location: U.S.A.
|
| Posted: Mon Apr 17, 2017 1:12 am Post subject: |
|
|
ticho says: | Quote: | | It is really weird that one has to do this on a system using "stable" arch keyword. |
Mine wasn't stable, very new system (March). Not stable, but not bleeding edge either. But you are absolutely correct, especially if new and stable.
Regardless. Have a RECENT backup. Just cause it worked on mine this way doesn't mean,....
_________________
Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Mon Apr 17, 2017 1:26 am Post subject: |
|
|
It seems you are forgetting some major points... First off, portage has been getting significantly better on dealing with updating perl and python over time; as it is right now, portage is a huge step forward to what it used to be. The next part to keep in mind (but often bites everyone in the butt) is that Gentoo is designed around being updated on a regular and semi frequent basis. Having a long break in between updates has always, and more likely will still be that in the future, a major problem producer. Next part that also often causes issues, is having dependency packages in your world file. The larger amount of packages in your world file, makes portage's job that much harder (hence why we recommend you use --oneshot/-1 when compiling dependencies).
| Quote: | | And the reason there is no sys utility to do all this is? |
The reason why the sys utility was removed, was because it has become redundant and wasn't needed anymore. The job that utility was doing was merged into portage, to help clear most of these issues before you encounter them. Sure, portage is not perfect and still needs a lot of work; but that is common for most applications to what ever purpose.
As asturm mentioned, one of the biggest jobs that portage has, is ensuring it doesn't break your system when you update; hence why it is generally considered better to fail before something may break. Like, do you really want an update to go through anyways, for you to find out half your system is broken because you were too lazy to ensure everything is linking to the correct place.
Side note: Just a small bit of food for thought, over the last year to year and half; I've rarely had to deal with these blocker issues compared to 2-3+ years ago. This is on my system where I am running unstable branch, meaning I am more likely to receive updates sooner and more frequently than stable branch, and have a higher chance of other issues to be mixed in. The last time I had to deal with an blocker issue, is when texlive got updated finally (approx a couple months ago), before that it has been well over a year. Now, the part that helps me quite a bit, is that I update my system on a weekly basis (I spend maybe 20 mins administering my system a week, mostly spent reviewing what the update is and going over the logs). |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Mon Apr 17, 2017 1:45 am Post subject: |
|
|
@ct85711,
FWIW I update my gentoo system every weekday, and I had a problem with updating perl that this thread helped me fix.
The problem is not isolated to infrequent maintainers. If I hadn't found this thread or one like it I would have had to ask for help. Perl has always been a PITA for Gentoo.
Last edited by 1clue on Mon Apr 17, 2017 1:51 am; edited 1 time in total |
|
| Back to top |
|
|
jserink
Veteran
Joined: 30 Jan 2004
Posts: 1008
|
| Posted: Mon Apr 17, 2017 1:47 am Post subject: |
|
|
I update my system everyday and this morning I had to do the perl dance......
After 30 minutes of trying to emerge -C to various packages to try and get the blocking to stop...
I gave up and used the --nodeps perl ....
I'm just finishing the perl cleaner all and will then put back everything I unmerged to try and get this to work. Am almost done, seems to be working.
So, I'm a datapoint....
I emerge --sync everyday and do an emerge -uDp system , emerge -uDp world everyday and I still ran into this.
I actually get a bit of a rush out of getting around these issues and getting my machine back to an operational state....I should have been working on two work proposals for the last two hours but have been doing this.....but, how would a newbee deal with this? They'd more than likely throw their hands up in the air and just move to Debian, Ubuntu or Fedora and just forget about it.
See the problem? Its a kooky state of affairs.
Cheers,
John |
|
| Back to top |
|
|
ct85711
Veteran
Joined: 27 Sep 2005
Posts: 1791
|
| Posted: Mon Apr 17, 2017 5:50 am Post subject: |
|
|
| Quote: | ...how would a newbee deal with this? They'd more than likely throw their hands up in the air and just move to Debian, Ubuntu or Fedora and just forget about it.
See the problem? Its a kooky state of affairs. |
The way I see it, Gentoo is NOT meant for a noob in linux. The reasoning that I see, is that Gentoo expects a certain level of knowledge and familiarity to setup and run from the very beginning. The biggest thing when dealing with Gentoo is that it is designed around working from command line. This is one thing most people have little knowledge about and maybe even a little bit, fear anymore. Even on Windows, most people on Windows have little to no knowledge on dealing with command prompt/powershell. Of course this is excluding System/Network Admins that end up learning powershell. Back on pre-Windows 95/98 most windows users was familiar with command line. For me, when I recommend people to use linux, I tell them to stay away from Gentoo and to use a different distro. This is not because I don't like Gentoo, which I do, it's more of I know their level of knowledge and don't want to scare them away from linux as a whole. I've only recommended Gentoo to one person, it is because of her knowledge of linux gives her a foundation to not be scared away form being thrown into command line straight away.
I will admit that portage still has some issues, specially dealing with these slot/subslot dependencies but this is not an easy thing to just fix. Think through what portage has to go through on deciding what packages need to be recompiled and in which order. When perl is updated all perl packages need to be rebuilt against the new version. Portage needs to look at all of them, and figure out which order those need to be rebuilt, and need to look at their dependencies on anything on them need to be rebuilt. Then you need to keep in mind, portage needs to compare that list to everything in your world file and their dependencies to build the new list. The part I often see as the troublemaker for portage is more of what to do with packages that is dependent on the slots they are compiled against (but not restricted by version), hence needs to be rebuilt along side them even though their dependencies are met. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
