Hi. So, trying to do a world update, I ran into two major problems --required by
one is perl and the other is python 3.12. Here is what I get trying
to upgrade perl by itself:
These are the packages that would be merged, in order:
Calculating dependencies .... ....... done!
Dependency resolution took 28.07 s (backtrack: 3/200).
[ebuild U ] dev-lang/perl-5.40.0:0/5.40::gentoo [5.38.2-r6:0/5.38::gentoo] USE="gdbm -berkdb -doc -minimal" PERL_FEATURES="(-debug) -ithreads -quadmath" 13,616 KiB
Total: 1 package (1 upgrade), Size of downloads: 13,616 KiB
!!! 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.40.0:0/5.40::gentoo, ebuild scheduled for merge)
USE="gdbm -berkdb -doc -minimal" ABI_X86="(64)"
PERL_FEATURES="(-debug) -ithreads -quadmath" pulled in by
=dev-lang/perl-5.40* required by
(virtual/perl-CPAN-2.360.0-r1-1:0/0::gentoo, installed) USE=""
ABI_X86="(64)"
^ ^^^^^
=dev-lang/perl-5.40.0 (Argument)
(and 35 more with the same problems)
(dev-lang/perl-5.38.2-r6-1:0/5.38::gentoo, installed) USE="gdbm
-berkdb -doc -minimal" ABI_X86="(64)" PERL_FEATURES="(-debug)
-ithreads -quadmath" pulled in by
dev-lang/perl:0/5.38= required by
(virtual/perl-CPAN-Meta-YAML-0.18.0-r10-1:0/0::gentoo, installed)
USE="" ABI_X86="(64)"
^^^^^^^^
dev-lang/perl:0/5.38=[-build(-)]
(dev-vcs/git-2.45.1-1:0/0::gentoo, installed) USE="blksha1 curl gpg
iconv keyring nls pcre perl safe-directory webdav -cgi -cvs -doc
-highlight -mediawiki -perforce (-selinux) -subversion -t\est -tk
-xinetd" ABI_X86="(64)" PYTHON_SINGLE_TARGET="python3_11 -python3_10
-python3_12"
^^^^^^^^
\
=dev-lang/perl-5.38* required by
(virtual/perl-Socket-2.36.0-1:0/0::gentoo, installed) USE=""
ABI_X86="(64)"
^ ^^^^^
(and 308 more with the same problems)
NOTE: Use the '--verbose-conflicts' option to display parents omitted
above
!!! The slot conflict(s) shown above involve package(s) which may need
to
!!! be rebuilt in order to solve the conflict(s). However, the
following
!!! package(s) cannot be rebuilt for the reason(s) shown:
(dev-vcs/git-2.45.1-1:0/0::gentoo, installed): ebuild is masked or
unavailable
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.
!!! The following installed packages are masked:
- xfce-base/xfconf-4.19.2::gentoo (masked by: package.mask) /var/db/repos/gentoo/profiles/package.mask:
# Micha\u0142 Górny <mgorny@gentoo.org> (2024-06-08)
# Prereleases of Xfce 4.20. Masking upon popular request, due to
# a large number of regressions in every new release.
- dev-php/PEAR-Mail-1.5.0::gentoo (masked by: package.mask) /var/db/repos/gentoo/profiles/package.mask:
# Viorel Munteanu <ceamac@gentoo.org> (2024-06-11)
# dev-php/pear, dev-php/PEAR-* and their reverse dependencies: mask
for removal
# in 30 days.
## they have around 40 bugs.
# Removal: 2024-07-11. Bug #933998.
- xfce-base/libxfce4util-4.19.3::gentoo (masked by: package.mask)
- dev-php/PEAR-DB-1.11.0::gentoo (masked by: package.mask)
- dev-build/xfce4-dev-tools-4.19.1::gentoo (masked by: package.mask)
- dev-php/PEAR-Date-1.5.0_alpha4-r1::gentoo (masked by: package.mask)
- xfce-base/exo-4.19.0::gentoo (masked by: package.mask)
- dev-php/PEAR-XML_Serializer-0.21.0-r1::gentoo (masked by:
- package.mask)
- xfce-base/libxfce4ui-4.19.5::gentoo (masked by: package.mask)
- dev-php/PEAR-XML_Parser-1.3.8-r1::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
I tried with backtrack=1000, with no different results.
Thanks in advance for any suggestions.
Thanks in advance for any suggestions.Whenever I have a problem involving perl I first run:
/usr/bin/perl-cleaner --reallyall
I don't know if it will fix your problem, but it won't hurt trying this first.
Wols Lists wrote:
On 01/07/2024 11:34, Michael wrote:
Thanks in advance for any suggestions.Whenever I have a problem involving perl I first run:
/usr/bin/perl-cleaner --reallyall
I don't know if it will fix your problem, but it won't hurt trying
this first.
Yup. I discovered this. A lot of perl stuff doesn't seem to get
updated in the normal course of updates, and all of a sudden perl
itself gets wedged.
Bear in mind large chunks of Perl are downloaded from CPAN, and the eco-system is designed to upgrade them from inside Perl itself, you
can see how things go wrong ...
Cheers,
Wol
I seem to recall having to run that during that upgrade as well. It reinstalled a lot of packages but it worked. It's worth trying for sure.
I seem to recall having to run that during that upgrade as well. ItBut don't you do that after the upgrade -- I can't even start the
reinstalled a lot of packages but it worked. It's worth trying for sure. >>
upgrade, so how would perl-cleaner help?
On 01/07/2024 20:27, John Covici wrote:
I seem to recall having to run that during that upgrade as well. ItBut don't you do that after the upgrade -- I can't even start the
reinstalled a lot of packages but it worked. It's worth trying for sure. >>
upgrade, so how would perl-cleaner help?
Trust me it does!
You have a bunch of old perl scripts, one (or more) of which are
blocking the upgrade. perl-cleaner will upgrade them to the
latest version compatible with your current perl, which then
frees up the perl upgrade. Make sure you run perl-cleaner again
afterwards, to ensure you have the absolute latest version of all
these extra bits. In fact, you should really run perl-cleaner
after every "emerge --update". Most people most of the time
either forget or don't realise ...
Don't forget, if I've got it right, perl and CPAN predate linux,
so if there's an argument about who needs to change, perl simply
says "I was here first, you have to do it *my* way".
Cheers,
Wol
IMO, only bring out the hammer if you're having a problem.
Eli Schwartz wrote:
On 7/2/24 7:33 PM, Dale wrote:
What I wish, emerge would spit the information out after it completes
instead of putting fairly important info in some log files somewhere for >> a person to go dig and find. It already tells us we should run
--depclean. Why can't it tell us when we need to run some python tool,
perl or anything else as well that has been triggered. I've never seen
emerge tell me to run anything but --depclean or preserved rebuild and
to be honest, if a package isn't used, it likely doesn't hurt anything
that it is still installed. It's just cruft left behind. Having a
broken python, perl or some other important package should give us a
notice at the end. That to me would be more important than running
-depclean. Running preserved rebuild is important tho.
One thing about it, if it doesn't need to fix anything, I guess it does
nothing. Might upset a few electrons while checking is all. ;-)
... but it already does exactly this?
When a package emits a warning in the middle of 50 other packages being compiled and installed... portage collects warnings and repeats them at
the end for you.
It doesn't matter because the package manager already rebuilds pretty
much all perl modules. Running perl-cleaner is advised "in case portage missed something" which probably means "it wasn't part of @world".
All I've ever seen is --depclean and preserved rebuild. I don't recall
ever seeing anything else. If a package fails, then it tacks the log
file on the end, sometimes of multiple packages. To be honest tho, if
it fails, most of the time that isn't useful either. Usually the actual error is way up somewhere. I've never seen anything about perl, python
or that sort of thing before.
It could be that my emerge options are good enough that it doesn't
trigger any of those. When I had to run perl cleaner a while back tho,
I wish emerge had gave me a hint that it needed to be run if it couldn't
fix it itself. Then again, it may not have known about it either.
I plan to run it and if it does nothing, at least then I know my system
is set up correctly. It's better than not doing it and having weird
problems that are hard to figure out the cause of.
Dale
:-) :-)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 159:02:05 |
| Calls: | 10,384 |
| Calls today: | 1 |
| Files: | 14,056 |
| Messages: | 6,416,490 |