Re: [gentoo-user] State of emergency is now in effect.

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 5960 bytes --]

On Saturday, 30 January 2021 09:37:57 GMT Alan Grimes wrote:
> I'm not actually talking about the communist takeover of the planet, I
> mean I'm looking at what this brokenest version of portage EVER is not
> doing...
> 
> I mean I always update my portage first thing after sync, because that's
> what you do, RIIIIIGHT????

Not RIIIIIGHT.

I let portage decide when it needs to update itself, after it has decided 
which of its dependencies it may need to update first.

When I'm driving a car with an automatic gearbox I don't start changing gears 
myself, unless something breaks and I *have* to.


> I know you hate my scripts but they have a 15 year track record. =|

I'd leave others to comment on the suitability of your loop-a-loop scripts, 
which often tie themselves up in a knot and typically result in your moaning 
posts on this M/L.


> On one terminal I have this bullshit going on, at this pace it will take
> longer than my natural lifespan to clear this nonsense:
> ######################
> 
> tortoise ~ # ./pretendupdate                     
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> 
> 
> [ebuild   R    ] app-officeext/sun-templates-1.0.0-r1::gentoo 
> OFFICE_IMPLEMENTATION="libreoffice (-openoffice%)" 0 KiB
> [ebuild     U  ]  app-office/libreoffice-7.0.4.2::gentoo
> [6.4.7.2::gentoo] USE="branding clang%* cups custom-cflags%* dbus
> gstreamer gtk java mariadb vulkan%* -accessibility -base -bluetooth
> -coinmp -debug -eds -firebird -googledrive -kde -ldap -odk -pdfimport
> -postgres -test" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell
> -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_8*
> -python3_7* -python3_9 (-python3_6%)" 347,325 KiB
> [ebuild  N     ]   dev-java/openjdk-11.0.9_p11:11::gentoo  USE="alsa
> cups jbootstrap pch -debug -doc -examples (-gentoo-vm) -headless-awt
> -javafx (-selinux) -source -systemtap" 89,491 KiB
> 
> Total: 3 packages (1 upgrade, 1 new, 1 reinstall), Size of downloads:
> 436,815 KiB
> 
>  * Error: circular dependencies:
> 
> (dev-java/openjdk-11.0.9_p11:11/11::gentoo, ebuild scheduled for merge)
> depends on
>  (dev-java/openjdk-11.0.9_p11:11/11::gentoo, ebuild scheduled for merge)
> (buildtime)
> 
>  * Note that circular dependencies can often be avoided by temporarily
>  * disabling USE flags that trigger optional dependencies.


Did you try removing the java USE flag from app-office/libreoffice as emerge 
suggests above to see if it proceeds?

Alternatively, you could unmerge dev-java/openjdk and see what portage wants 
to bring in.

Using '--depclean -p -v' on dev-java/openjdk before you unmerge it will show 
you what else could break.


> !!! 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.32.0-r1:0/5.32::gentoo, ebuild scheduled for merge)
> USE="berkdb gdbm ithreads -debug -doc -minimal" ABI_X86="(64)" pulled in by
>     =dev-lang/perl-5.32* required by
> (virtual/perl-XSLoader-0.300.0-r3:0/0::gentoo, installed) USE=""
> ABI_X86="(64)"
>     ^             
> ^^^^^                                                                       

Perhaps a run of 'perl-cleaner --reallyall' is in order before you proceed.


>     (and 46 more with the same problem)
[... snip]

> Notice, it's only giving me ONE package at a time to remove, it takes
> about 10 minutes to get through a cycle of this nonsense. Wait a minute,
> what kind of bullshit is this "--verbose conflicts" faggotry? why isn't
> it the default and impossible to disable????  I mean that would have
> saved me hours today...  I've been putting out all kinds of fires on
> this turd sandwitch of a distro since I decided to update today.

Doing it manually, one package at a time is a rather long winded approach.  
Using perl-cleaner is better and easier in this case.


> fuckit, I'm adding this shit to the goddamned, cock-sucking make.conf
> and there's nothing you can do to stop me!!! Why for fuck's sake do I
> have to fix this shit at 4:30 am and can't get it all done in the middle
> of the afternoon when I started???

Enjoying a self-induced crisis of tourettes at 4:30 am is your prerogative.  
Using portage and associated tools the way devs intended should bring more 
satisfactory results.


> Why am I required to manually update a dozen config files just to get
> things moving each time I do this?? Is it really impossible to just keep
> doing what I set up last time?, you know the time when I stopped messing
> with it because it was working???
> 
> 
> Do you have any idea how broken it is right now? It will look like it's
> emerging stuff, then start no processes, decompress any files, compile
> any code, or anything, just tick through as if it were working very very
> very slowly but not actually do anything...
> 
> So this version of portage is the first one I've seen that is literally
> incapable of emerging a pacakge!   Unbelievable, a package manager
> incapable of performing its primary function...
> 
> I have no idea how I'm going to fix this mess this time, I'm going to
> have to mask the current version of portage and get a binary of one that
> is capable of emerging and put that in.
> 
> How did you break it this bad, HOW???? 
> 
> All you had to do was nothing and it would still be working!!!

Your particular approach to managing your system(s) tends to arrive at similar 
unhappy results.  There is a pattern here and on this M/L it is an outlier.  
You could modify your approach to improve the results, or you could carry on 
repeating the same thing and somehow retain an expectation of a different 
outcome.  This is not an ad hominem criticism, just my observation on your 
approach.  I'm not saying portage is the best thing since sliced bread.  
However, using it as intended works most of the time for most of the people.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]