On 05/20/20 22:08, Rich Freeman wrote:
On Wed, May 20, 2020 at 3:49 PM n952162 <n952162@web.de> wrote:

On 05/20/20 21:24, Daniel Frey wrote:

On 5/20/20 12:06 PM, n952162 wrote:

The command was:

emerge -vu dev-qt/qtgui dev-qt/qtx11extras dev-qt/qtopengl
dev-qt/qtprintsupport dev-qt/qtwidgets dev-qt/qtxml
dev-qt/linguist-tools dev-qt/qtnetwork dev-qt/qtsvg dev-qt/qtcore

The output to that is attached.

I tried just emerging zlib with the static-libs USE flag ... that log is
also attached.

On 05/20/20 18:59, Ashley Dixon wrote:

On Wed, May 20, 2020 at 02:35:52PM +0200, n952162 wrote:

I have a slot conflict for sys-libs/zlib, whereby both users want
the same package.  Studying the USE variables shows that the new
package wants, additionally, the "static-libs" USE flag.

I thought, the way to handle this is to add the static-libs USE
variable in /etc/portage/package.use and re-emerge with
--changed-use.  Unfortunately, that gives me the same conflict.

Can you attach the full output of emerge ?



          

          
This is most likely due to so many packages that need to be upgraded
at the same time. You're only asking to update a few select packages
and it's borking because it's finding packages outside your request
that also need to be updated at the same time.



        

        
Because of a static-libs USE flag?
Is it the case that - if a package is installed with a USE flag, every
user of that package that doesn't specify that USE flag gets kicked out?


      

      
No.  The problem is that you asked the system to update a few packages.

Those packages require an updated version of openssl to work.
However, you have a  bunch of other packages (like
openssh/wget/ruby/curl/etc) that use the old version of openssl.

    

    

    

    Well, you're talking about openssl here.  I'm trying to go a step at
    a time and looking at the first conflict in that first log file:
    zlib.  Why will 

    

    sys-libs/zlib:0

    

      (sys-libs/zlib-1.2.11-r2:0/1::gentoo, installed) pulled
      in by

        >=sys-libs/zlib-1.2.8-r1[abi_x86_64(-)]
      required by (dev-libs/glib-2.52.3:2/2::gentoo, installed)

    ...
                                                                                                                                                                                                                                                       
    

    

      (sys-libs/zlib-1.2.11-r2:0/1::gentoo, ebuild scheduled
      for merge) pulled in by

        >=sys-libs/zlib-1.2.8-r1[static-libs(+)?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_s390_32(-)?,abi_s390_64(-)?]
      required by (dev-libs/openssl-1.1.1g:0/1.1::gentoo, ebuild
      scheduled for merge)

                                                                                                                               
    

    

    Why would these packages need an updated version of zlib if the only
    thing different to what they currently have is that the new version
    has the libraries linked in to it - one less load-time dependency:

    

    
dev-libs/glib-2.52.3:2/2::gentoo

      media-libs/mesa-18.1.9:0/0::gentoo

      dev-libs/boost-1.65.0:0/1.65.0::gentoo

      media-libs/tiff-4.0.9-r4:0/0::gentoo

      net-misc/curl-7.61.1:0/0::gentoo

      app-arch/libarchive-3.3.1:0/13::gentoo

      dev-libs/nss-3.37.3:0/0::gentoo

      media-video/ffmpeg-3.3.6:0/55.57.57::gentoo

      media-libs/libpng-1.6.34:0/16::gentoo

      net-libs/libssh2-1.8.0-r1:0/0::gentoo

      dev-libs/libxml2-2.9.8:2/2::gentoo

      net-libs/gnutls-3.5.19:0/30::gentoo

      sys-libs/binutils-libs-2.30-r4:0/2.30-r1::gentoo

      dev-db/sqlite-3.24.0:3/3::gentoo

      x11-libs/cairo-1.14.12:0/0::gentoo

      dev-libs/openssl-1.0.2p:0/0::gentoo

      sys-apps/pciutils-3.5.6:0/0::gentoo

      sys-apps/file-5.33-r4:0/0::gentoo

      x11-libs/libpciaccess-0.14:0/0::gentoo

      dev-libs/elfutils-0.170-r1:0/0::gentoo

      sys-libs/cracklib-2.9.6-r1:0/0::gentoo

      media-libs/freetype-2.9.1-r3:2/2::gentoo

      

    

    

    

      

So portage is going to try to rebuild those packages for you.
However, it can't do that, because the versions you have installed are
so old that their ebuilds are no longer in the repository, so portage
doesn't know how to rebuild them.

    

    

    

    Isn't the source and build instructions to everything on my system
    here, too?

    I mean, if it had to rebuild all the users of zlib, but wasn't being
    requested to update them.

    

    

    

      

Portage can't upgrade them either, because you told portage to only
update that small list of packages and their dependencies, and those
other packages aren't dependencies of the packages you listed.

You can either try to get the update for all of @world to work at the
same time.  Or you can try to add more packages to the list.

    

    

    Tried that.  The sorry results are attached ...

    

    

      

And make sure you use -1 or --oneshot on the command line.

    

    

    Yes, I've finally grasped that, thank you, all.

    

    

      

If you added all the packages from that list (without version numbers)
to that command line that might help.  That is the list starting with
wget and ending with virtualbox (and 4 more) - you'll need to either
add --verbose-conflicts to get the 4 more, or see what else pops up
after you add these packages to the list.

    

    

    

    Okay, that's a good tip - when I get to openssl.  But I think I
    should be able to solve zlib, first....

    

    

    

      

Something that might also help is running:
emerge -auDv --changed-use --keep-going --with-bdeps=y --changed-deps
--backtrack=100 @system


    

    

    Attached ... 

    

    

      
That is going to be another big update, but much smaller than @world,
so maybe you'll get fewer errors to have to resolve that way.  I'm not
sure if that will be better or worse than dealing with all of @world.

It will probably take you a while to manually resolve all the
conflicts this way - this is a pretty normal occurrence if you update
Gentoo only once a year/etc.  Obviously I have a half decent idea of
the sorts of issues you're running into and sorting through this mess
would probably take me days unless I just did nothing else.  This is
not a situation you want to be in normally.

You could also try doing a progressive update by pulling git snapshots
of the repository a month or two apart since the time of your last
update.  Then you won't have so many changes to do at each time.
However, you might run into issues if source files aren't available,
since you're now trying to install packages that will no longer be
mirrored.



    

    

    Actually, I installed this system just a month or two ago, but I
    used a CD I burned of the minimal-install-disk that is perhaps a
    year old.  I wanted to have all my systems have the same basis,
    until I proficient enough to do a stage-1 installation ... I guess
    this is the way I'm learning how to get there  :-(