Gentoo Out of Date Systems - My Experience

[Irre]

[mir3x]

For many years i was using such not very cool approach, but it was quite effective ( i was on ~amd64):
1) keep in world only few packages ( eg. I had gcc, kdevelop, google-chrome, some lxqt packages, smplayer qbittorrent, kate), dont update too often, next day there could be r1 version ..., use eix-sync to see if there is anything interesting to update
2) never do --depclean, if u want to test come packages with lot of deps - use demerge
3) Never update with --deep if everything works
4) If update doesnt work check again next week ( eg. some compile errors), it might be fixed next week.
5) If update still doesnt work and its compile/include/configure error try with --deep.
6) If nothing works run "EIX_LIMIT_COMPACT=0 eix -cu --only-names | sed ':a;N;$!ba;s/\n/ /g'", copy output and
emerge it all with --nodeps ( it shouldnt happen more than once per year), repeat that step, resolve rest conflicts by hand, there shouldnt be much left.

And master rule should be - set PORTAGE_NICENESS="19" in make.conf, if u still see any desktop slowdowns while emerging use and configure verynice utility.
_________________
Sent from Windows

[josephg]

[The Doctor]

--deep is perfectly safe, it just adds time to the emerge. May or may not be acceptable.

--depclean is safer than -C since it won't remove something with that is depended on. --depclean is still dangerous and should be run with the --ask flag first to make sure it is behaving and not removing nano.

Oh, and gcc shouldn't be in world. mir3x probably had some maintenance creep. A good rule of thumb is to add -1 to any rebuilds so they are not added to world.

The thing with updates is that if you do them daily then you will have fewer problems but weekly or monthly should be good enough.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.

[Hu]

[Irre]

[C5ace]

[Cyker]

Ugh it is ironic I just stumbled over this thread after spending about 40-Cyker hours bringing a 200-day old portage up to date!

It stalled because I was sick of the constant movement of kde packages in the tree breaking kde-sunset every time I emerge --sync'd so I tried to fork kde-sunset into kde3-sunset and put everything into kde3-base/misc so they wouldn't be affected. I was doing it on and off so it took ages.

Managed to get it all done, hand-patched my /var/db/pkg and ran an "emerge --everything-all-deps-and-kitchen-sink world" and everything was awesome.

Then I ran emerge --sync to bring everything up to date and everything on my system broke and I had to do it all again.

After masking off a load of stuff and pushing through some major changes (gcc, qt5, and letting gtk pull in that svg dep I've been manually patching out for the past year... how can one dependency be such a PITA?!) I finally got it up and running, although one huge irony is that something to do with either cmake or gcc has broken my kde3-sunset so all that effort that went into that that triggered all this turned out to be pointless anyway!

On the bright side that was the push I needed to try the TDE overlay by Fat-Zer and aside from a minor glitch due to a newer perl it actually worked pretty smoothly and I was able to copy my kde profile over so everything works as it did before. Happy days!


But I consider this ease of breakage one of gentoo's biggest flaws. Running emerge --sync && emerge --update world should be a trivial and safe thing but it feels like every 5th time I do it something will break the system and require me to spend a few hours fixing it. My package.[mask||keywords||use] and local overlay are terrifying to look at where I've had to patch out so much stuff to keep one thing working.

I wish there was a profile for people like me that would keep the core system and toolchain stable while letting me upgrade the 'ends' without having to allocate a whole weekend in case of fallout.

Oh, and a shoutout to demerge - That should be a standard tool, fantastic safety net. It has saved my bacon so many times! I always run it before a big emerge... I just wish there was a way of doing that with emerge --sync too!

[Hu]

[Cyker]

Well my ideal distro would be some combination of my old Slackware install and Gentoo.

I was originally on Slackware and just had the core system, and hand compiled everything else I added to it.

Had that for years with no problems, but started running into problems where the source tarballs I was compiling wouldn't tidy up after themselves. Then Gentoo came along and I thought Portage sounded exactly like what I was missing from my franken-Slackware:

A way of compiling stuff from source so that it would work on the system as-is, AND kept track of it so it could be cleanly replaced.

Gentoo does that well, but lacks the stable core that I had in Slackware which is why I am indeed having to do so much maintained.

It's been suggested Funtoo might be an alternative that follows this more, but I'm reading they're getting rid of their 'stable' profile so I'm not sure how accurate that is now...

My whole problem is I use Linux because I want it to do what *I* want it to do, not what other people want it to do. Otherwise I'd be using MATE or Windows. If I did I'd be forced to use an environment that I hated (Gnome3, KDE4/5) and I'd have to be constantly re-doing things that worked just fine but were obsoleted because of whatever reason.

If I could only find a way of emerge --sync'ing in a way that the core stays stable but the edges can be cutting edge then my life would be so much simpler!

[josephg]

[Tony0945]

[Hu]

I sympathize with your intended usage, but my remarks above stand. Projects make changes (sometimes for the worse) and sometimes gain annoying dependencies. You can mitigate this somewhat by using stagnant projects that rarely do anything they can avoid doing, but that's a careful balance not just to find a project with the features you want, but to find a maintainer inactive enough not to make unwanted changes, but still active enough that the package is not dropped when its dependencies demand it adapt. If you want to use a more actively developed project, and you disagree with some of its changes (but agree with others), be prepared to spend your time fighting those unwanted changes.

[Cyker]

@Troy - Ooops I meant to say MINT, not MATE!

@Hu - Yeah that is kinda what a bunch of us seem to be doing, but we accept it as the price of entry... just wish it wasn't such hard work sometimes!

It's compounded when seemingly arbitrary changes to the tree are made; The KDE thing has been the most recent thing for me (It's gone from kde-base and kde-misc to kde-apps, kde-base, kde-frameworks, kde-plasma and kde-misc and why?!), but I also remember things like samba being split into multiple parts, then merged back into one big part, then split into multiple, different parts, which caused merry hell with my overlay back then!
Other bug bears are things like dependencies, where I *know* some packages don't actually depend on stuff but for some reason the useflags for those things are taken away and they are made hard dependencies, with no explanation given (You used to have ChangeLogs which *might*, if you were lucky, point it a bug #, but even these seem to have been taken away!)

I also really really miss the old CVS ebuilds area where you could see what changes had been made between versions and retrieve old ebuilds if you needed to.
The new GIT one is awful for this purpose - It has taken many large steps backwards in terms of usability. I suspect you have to be an experienced developer to make head or tail of the thing!

I'm glad some of you 'make it do what I want it to do' people have popped up in this thread so I know it's not just me! The border-line hostility I've occasionally had on this forum when asking for help adapting unsupported packages that have fallen out of tree had been a bit disheartening in the past!

[NotQuiteSane]

[Hu]

I'm a minimalist, so I don't use KDE or GNOME. However, I remember the moves you're describing and agree that would make a mess of private trees. Sometimes, the split/merge/split dance is trying to follow upstream's preferences on how things should be built. Other times, it's a purely internal decision, often based on the complexity vs the savings of letting people build exactly what they need and no more.

If you can find other people in a similar position, perhaps you can co-maintain an overlay for this purpose. It would let you spread the work over the group instead of burdening every member with rediscovering and redoing the same updates as the main tree moves. Overlays don't need to be hosted on Gentoo infrastructure, so you could put it anywhere that all of you have write access, such as a public Git tree.

[eccerr0r]

[eccerr0r]

After putting my bad system on the backburner and coming back to it today, I figured out how to get around my blocks and saved another reinstall *sigh of relief*.

1 - the circular deps with udev, libudev virtual, and util-linux - I just emerge --nodeps all three of them, and it got through.
2 - I trimmed VIDEO_CARDS to the absolute minimum for the machine temporarily ( this disk was meant to be a generic disk to boot any old machine...)

After these two fixed/simplified, portage with --with-bdeps=y and --backtrack=40, was finally able to resolve all the blocks. I'll fix VIDEO_CARDS back after it cleans this up and take out the extras that don't work...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[josephg]

[eccerr0r]

The merge of the first batch updates succeeded.

Now I restored the VIDEO_CARDS line in make.conf back to what it was and Portage is able to resolve these updates now.
Perfect. Another Gentoo install saved from a reinstall.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[C5ace]

[josephg]

[josephg]

found a relevant wiki for my above query: http://wiki.gentoo.org/wiki/distcc/Cross-Compiling

i understand using binpkgs can really help updating older (out of date) gentoo systems

[jonathan183]