[split] Perl upgrade, no updates for 1 year 250 days

[segmentation-fault]

Split from Blockers or slot conflicts on a Perl update? --pjp

Let me give you a fresh (2022) look on this, from a "user perspective":

Some CAUTION is needed here: I am going to post the part of my notes that is related to Perl upgrade on a system that had not been updated for 1 year and 250 days. Someone above said "my mistake". Let me make it clear that it is a fundamental user right to have absolute control over the who, when and why of a system update! The user should dictate when and how often the updates take place, NOT the other way round! This should NEVER be negotiable - if it is, then it is a sign that something has gone wrong. But this is another story.

Regarding CAUTION: I am not going to redact my notes, in order to give you my unfiltered strong feelings about how things should work. Now, my notes do contain rants. But please don't think that this post is a rant, OK? It is not.

So, are you ready? There you go!

###########################################

Now, to make some more progress, I tried Perl:

First upgrade perl-cleaner:

[Hu]

[segmentation-fault]

My dear Hu, where do I start now...

You made a very thorough effort and many thanks for this. I warned everybody from the start to not interpret my post as a rant, even if there are rants in my notes - I hope you did not get offended. If you did, please accept my apologies. As I said, I wanted to give a fresh, unfiltered view of my upgrade hell, not to rant and "not be nice". I have no reason not to be nice, because I am sure that everybody does his/her best here. However, we can do better - that's my message.

I have the feeling that we are talking past each other. So I will try to answer top-down, from general views to specifics. This is because we approach portage with fundamentally different expectations - and I guess that's where the problems start.

You say it is "best practice" to upgrade often. I say, no, no way, never! It's even worse: when I see that it takes me 2 full man-months to upgrade, next time I even think about an upgrade, I say to myself "no, not now!". But, am I "responsible" for the mess that I have when I do try to upgrade? You say yes, because I created such a complicated dependency graph, which is "impossible to resolve". I say no, because I expect my package manager to work even in that scenario!

How?

Here's how: I know that the perl package does not have a 'postgresql' flag - but what if it had one? What would portage do then? In my case, it would think "oh I have circular dependencies, I cannot do anything here!". My point is: when I say "upgrade perl", I don't care (and portage should not care either) if some installed package will break because it has the 'perl' flag set and needs to be rebuilt. It should upgrade perl, making sure that it pulls-in the direct dependencies of perl - and that's all, thank you.

At the very least, there should be an option (say, --ignore-use-flag-induced-rebuilts) that would make it ignore all packages that have the 'perl' use flag when it upgrades perl. It should print a warning that now a second emerge run is needed, this time with "--deep" and "--newuse", to ensure that packages who use perl will not be broken in their Perl functionality - and that's all. The rest is in the responsibility of the user.

Why?

Because, when I am upgrading, I am upgrading and don't work - at least not with the functionality I am currently upgrading. To stay on the example, when I upgrade Perl, I will not be using the Perl bindings of my PostgreSQL and when I upgrade Ruby, I will not be asking my vim to use Ruby at exactly that moment. I know I am upgrading. I will take care of PostgreSQL and vim and their bindings in a second and third step. All will be good again - and if it's not, let that be my problem. But refusing to upgrade Perl, because some remote, distant, irrelevant program has the 'perl' flag set is, well...counterproductive.

Trying to enforce a consistent state across the whole dependency graph, and fail hard if this is somehow harder than with the miniscule graphs you get when you update daily - that' s a recipe for disaster. Saying to the user "your fault that you have such a big graph, you are alone now" is outright user-hostile.

Give us the tools and we will finish the job!

We need a way to "upgrade perl and its modules only", "ruby and its modules only", "Qt only", without the packages that have a 'perl', 'ruby' or (possibly) 'qt' USE flag. If it is difficult to program a --ignore-use-flag-induced-rebuilts option that could calculate the list of the packages-to-be-excluded, then may be it is easier to copy the functionality of the --exclude option and make a --exclude-packages-with use-flag-set 'some user-provided list of USE flags, separated by space' option. Instead of having to disable the 'perl' use flag in all packages that have it set, upgrade Perl, then reset the flag in all those packages back, then re-rerun emerge with --newuse, I would just run 'emerge ... --exclude-packages-with use-flag-set "perl"', then - at some later point of my choice - I would run 'emerge ... --newuse ...'.

That's power to the user, responsibility to the user, tools for the user - all I ask for. Not indoctrinating him about supposedly "best" practices that have been defined to retroactively fit existing inadequacies of a stiff status quo.

[segmentation-fault]

Let me give some answers to "specifics" here...As I said, you have done a very thorough effort, dear Hu, and it's not going to be easy for me - but I'll try. As always, please remember: my purpose in opening such a Pandorra box is to make portage better - and ultimately Make Gentoo FUN Again (TM)! - no rants, I promise!

So let's see:

[segmentation-fault]

More "specifics":

[pietinger]

segmentation-fault,

I am using Gentoo nearly the past 20 years. I love Gentoo. Therefore I love everyone who loves it too and want to make it better

I am an old and paranoid (for IT security) man (and no native english speaker). I want to tell you some of my beliefs - also from a "user perspective" (= please forget my moderator status). Maybe you will think its great nonsense, but maybe you think about ...

[pjp]

Split from the original thread. Not updating for nearly 2 years puts this into a category unrelated to normal scenarios.

Put in Gentoo Chat as it appears resolved. In addition, if it looks like a duck, walks like a duck, and quacks like a duck, its a duck (if you rant in your notes, then the post reads like a rant). Ranting isn't inherently a problem, but it can easily become inappropriate in support threads.

Actively making a choice to not update in such a long period of time does not warrant such ranting about tooling or how long support for updates should be provided.

Constructive discussion about how support could be provided for longer periods of time on old software is fine. The problem is ultimately one of human time required for maintenance and mostly not a technical problem. Although if you have a technical solution, I'm sure many people would love to see a demo.
_________________
Quis separabit? Quo animo?

[Hu]

[Irre]

Why not temporary remove the world file. Then update your system. Then restore your world file, possibly in small steps.

[NeddySeagoon]

or do some of the intermediate steps that were missed by the neglect.

Like eating an elephant, do it one plateful at a time. :)
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[segmentation-fault]

[segmentation-fault]

[figueroa]

Yes, it was a rant. That's OK, as it was interesting. A log of electrons have been used to coax you along. Bless their hearts.

This has been said before -- Gentoo follows upstream and upstream continues to accelerate at an increasing rate.

What used to be OK, updating a few times a year has evolved into a major ordeal. This requires updating more frequently to avoid the ordeal.

My main desktop and main collocated server I now usually update daily. The three other Gentoo machines I maintain I update at least once a month. The daily updates take almost no time at all. The other machines take a little more thought, but I don't watch them compile and on a monthly basis isn't usually messy and takes very little of my time most months.

In the meantime, I am fastidious about reading the news and following the advice contained therein as doing so makes the major issues easier.

Don't be left behind. It's your choice. The problems are not in Gentoo. A poor workman blames his tools. https://thecontentauthority.com/blog/what-does-it-is-a-poor-workman-who-blames-his-tools-mean
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi

[segmentation-fault]

[segmentation-fault]

[alamahant]

I was wondering if
https://wiki.gentoo.org/wiki/Upgrading_Gentoo#Preparing_the_intermediate_build_chroot
would have helped somehow.
Ease the pain a bit...
_________________

[pingtoo]

I agree with most of segmentation-fault point. It is a scale issue. when changes are few emerge feel ok, but for a very long delay update emerge just feel wrong. If emerge does not hold the concept to solve the problem in one shot and accept some kind of segmentation (no pun intended), for example use day range with git history. This may feel less painful.

For example I plan to build a binhost for my RPI4 desktop. I clone portage tree. branch out on each significant date on portage news and update binhost to that point then move on to next branch. This way I can have working environment for my everyday use and enjoy of solving emerge update problem at manageable scale.

This slow update idea is not mine, I lean from NeddySeagoon.

BTW, I never able to find where in Gentoo official document stated that user of Gentoo need frequent update or what is the frequency. I wonder if it is stated officially that use of Gentoo require perform high frequency update and each update might take up to a day to complete, few will want to use Gentoo.

[figueroa]

[Hu]

[figueroa]

To assist with doing frequent (daily?) updates with the least possible waste of time, I automate certain preliminaries.

I have "emerge -- sync" followed by "emerge -uDU @world -p" run via root's crontab every morning at 7:15 am local. The output of "emerge --sync" is automatically emailed to me, and the output of "emerge -uDU @world -p" is also emailed to me with another small script. Here are the scripts. Adjust to suit your use case.

[figueroa]

[pingtoo]

@figueroa, Thanks for the information. I like your scripts.

[segmentation-fault]

figueroa,

thank you for your scripts. Although I don't think I will update daily, but who knows, maybe twice a year for the start...

[pingtoo]

A follow up in this gentoo update topic,

In old day it was suggested do emerge @system before emerge @world, Is this no longer required due to emerge capability improvement?

Will doing emerge ... @system May have helped in this case? at least reduce the frustration for performing update?

As Hu point out, using *set* concept could possible help in many situation, is there a way to promote (especially in handbook) more use of the *set* concept?

I personally use *set* concept to help in my binhost build process, so I can cut my emerge -uDN @world in to several days. I usually collect those failed ebuild into a set file so I will fix them in another day, and let thing that can be done finish. This way I can feel for each emerge involve I accomplish something.

[segmentation-fault]