What's changed in the last 7 or so years

[Shan]

So I used to be a hardcore Gentoo user (my first post was back in 03, don't recall how long I was using it before then); but about 8ish years ago I just didn't have time to maintain my systems the way I liked, and I either consolidated them or migrated to other distro's. Hell in all honesty I haven't even ran a Linux Desktop in around 5; though I've been playing around with some Pi's and I have a Debian based file-server built out of a scavenged laptop.

I just ordered the parts for a new HTPC / master file-server however and I thought now might be the time I'd pick up the ole Gentoo. Obviously I plan to treat myself as a newbie and RTFM's but I was hoping a few of the old-hats might be able to enlighten me of some of the major changes that might trip me up(both Gentoo specific and Linux overall). I know what I'm asking is kind of vague but as the quote goes "I don't know, what I don't know."

[steveL]

I was hoping a few of the old-hats might be able to enlighten me of some of the major changes that might trip me up(both Gentoo specific and Linux overall).

Biggest changes Linux-wise would be the udev monstrosity that has entangled everything.

Biggest change Gentoo side, imo, would be the multilib fiasco; expect portage to be much slower now than it used to be, though it was getting faster until about 16-18 months ago. Hint: set ABI_X86=64 and only enable what you have to on a per-package basis, or consider a 32-bit chroot. (That's not going to speed emerge up, but it will make your life easier.)

[VinzC]

@steveL:

Guess I am [topic=1021448]joining you[/topic] in your claim...

EDIT: @Shan: Good luck ,man. Good luck, really.

[The Doctor]

Welcome back, we always knew you would return.

Systemd has made an appearance. Be aware, this topic starts flame wars! Here are some facts:

Systemd has absorbed udev and eudev has been forked so it still builds independently. There is very little that is functionally different at this point, but Red Hat has been redesigning systemd constantly and their stated goal is to remove all other init systems and standardize all distros to systemd. (Everyone please note. I have not flamed for or against any init system here. Please do not take this post as an excuse to start!)

Research that to your heart's content and choose the init system you want to use. OpenRC is still the default in Gentoo, but Systemd is fully supported. Gnome has tied itself completely to systemd and KDE may as well.

IMO portage is still working very satisfactory, but my computer is quite powerful so I may be biased. There where many features added which accounts for the slowdown. For example, now portage rebuilds packages as needed so you don't have any broken libs and, failing that, preserves the old libraries failing that so the binarys still work and can be rebuild with emerge @preserved-rebuild. revdep-rebuild is basically obsolete now.

[Shan]

I was hoping a few of the old-hats might be able to enlighten me of some of the major changes that might trip me up(both Gentoo specific and Linux overall).

Biggest changes Linux-wise would be the udev monstrosity that has entangled everything.

Hmm without meaning to get into a potentially touchy subject, would you care to expand on that? I seem to recall udev being a good thing when it hit 2.6. It certainly seemed to make handling usb devices easier at the very least.

Biggest change Gentoo side, imo, would be the multilib fiasco; expect portage to be much slower now than it used to be, though it was getting faster until about 16-18 months ago. Hint: set ABI_X86=64 and only enable what you have to on a per-package basis, or consider a 32-bit chroot. (That's not going to speed emerge up, but it will make your life easier.)

Being slightly facetious here but I hope a brand new FX-6300 runs faster than an Athlon Toledo (What I last ran Gentoo on). I'm still slowly working my way through the handbook and noticing subtle differences (like whats the deal with the use of the @ symbol everywhere. @world, @EULA; and the handbook isn't even consistent.)

@steveL:

Guess I am [topic=1021448]joining you[/topic] in your claim...

EDIT: @Shan: Good luck ,man. Good luck, really.

All I can say is "ouch". To be honest; problems like yours is why I got away from Gentoo in the first place. I had less time to muddle through problems like that and eventually swapped to binary distro's. Of course, on the flip side the BS you experience with binary distro's is part of the reason I'm coming back.

For example my current Semi-HTPC/fileserv is running the latest version of Debian. Debian dev's *hate* ffmpeg and refuse to support it. Latest debian official ffmpeg is 0.8.17 (latest stable is now 2.7.1 for comparison). Ok, fine whatever I'll use libav like they want. Except libav doesn't have concatenation support built in. So I'd have to install the toolchain, hunt down all the deps and roll up my own version because the Debian dev's are in a pissing match with ffmpeg. If I'm going to do that I might as well run Gentoo anyways; atleast here I've got the ability to choose what functionality gets built into my system.

Welcome back, we always knew you would return.

Systemd has made an appearance. Be aware, this topic starts flame wars! Here are some facts:

Systemd has absorbed udev and eudev has been forked so it still builds independently. There is very little that is functionally different at this point, but Red Hat has been redesigning systemd constantly and their stated goal is to remove all other init systems and standardize all distros to systemd. (Everyone please note. I have not flamed for or against any init system here. Please do not take this post as an excuse to start!)

I'm getting a brief overview now. According to that out of the "major" distros only Slack and Gentoo don't use it by default; with Slack not even having the option.

Research that to your heart's content and choose the init system you want to use. OpenRC is still the default in Gentoo, but Systemd is fully supported. Gnome has tied itself completely to systemd and KDE may as well.

Fortunately I'll be free to make my own choice as I wont be running Gnome or KDE. Appreciate the heads up about the whole thing. Suppose I need to start digging into the specifics to figure out which I prefer.

IMO portage is still working very satisfactory, but my computer is quite powerful so I may be biased. There where many features added which accounts for the slowdown. For example, now portage rebuilds packages as needed so you don't have any broken libs and, failing that, preserves the old libraries failing that so the binarys still work and can be rebuild with emerge @preserved-rebuild. revdep-rebuild is basically obsolete now.

I have no problem with portage being a bit slower overall if it means I don't have to have a dozen scripts meant to handle broken revdeps and the likes.

[VinzC]

All I can say is "ouch". To be honest; problems like yours is why I got away from Gentoo in the first place. I had less time to muddle through problems like that and eventually swapped to binary distro's. Of course, on the flip side the BS you experience with binary distro's is part of the reason I'm coming back.

For example my current Semi-HTPC/fileserv is running the latest version of Debian. Debian dev's *hate* ffmpeg and refuse to support it. Latest debian official ffmpeg is 0.8.17 (latest stable is now 2.7.1 for comparison). Ok, fine whatever I'll use libav like they want. Except libav doesn't have concatenation support built in. So I'd have to install the toolchain, hunt down all the deps and roll up my own version because the Debian dev's are in a pissing match with ffmpeg. If I'm going to do that I might as well run Gentoo anyways; atleast here I've got the ability to choose what functionality gets built into my system.

Thanks a lot for sympathizing. I'd dislike to think of Gentoo as the «least worse» of all, against which in comparison Slackware'd look like a noob's paradise.

I sometimes sweat in horror (just kidding, almost) against how complicated computer things have become and how the minds behind the scene no longer are able to come up with simple and elegant solutions. Were I like twenty/thrirty years younger I'd go for making my own distro. Now I'd rather flee, care for my family and leave the rambling noise to the agitators. Life's too short to waste time bothering with things when they're too complicated by design.

[tclover]

Come on guys and stop that nonsensical bs about multilib... Now Gentoo has a proper multilib support without the old emul hacks which were flawed in every aspect especially for users who were using ~arch who did get older binary which caused multiple no trivial issues, not less. Indeed, for those that have some X, opengl, gtk, alsa, jack related multilib packages... would have to handle somes lines in packages.use. Just accept the auto-write option and then edit the result by trimming the packages version and maybe slot and the comments with a sed command to get somthing quicky workable without *too* much hassle.

And you are calling it a fiasco? What are you calling the old emulation libries then? Indeed, it could be more easier on the users... hoever, use flags shall be enabled for each package--nothing new here, it's just the default behaviour of portage here.

You do not need to set ABI_X86 yoursel because this is the job of the profile.

So, yes, proper multilib support in Gentoo which is a big change; maybe udev is another anone--just mere eudev manually and mask systemdebug and crap kit/hal before hand to get going.

Wellcome back!

[VinzC]

Come on guys and stop that nonsensical bs about multilib... Now Gentoo has a proper multilib support without the old emul hacks which were flawed in every aspect especially for users who were using ~arch who did get older binary which caused multiple no trivial issues, not less. Indeed, for those that have some X, opengl, gtk, alsa, jack related multilib packages... would have to handle some lines in packages.use. Just accept the auto-write option and then edit the result by trimming the packages version and maybe slot and the comments with a sed command to get something quickly workable without *too* much hassle.

And you are calling it a fiasco? What are you calling the old emulation libries then? Indeed, it could be more easier on the users... however, use flags shall be enabled for each package--nothing new here, it's just the default behaviour of portage here.

You do not need to set ABI_X86 yoursel because this is the job of the profile.

So, yes, proper multilib support in Gentoo which is a big change; maybe udev is another anone--just mere eudev manually and mask systemdebug and crap kit/hal before hand to get going.

I assume you didn't read [topic=1021448]my rant[/topic]. And if you did, same: you didn't get the point. Placing myself as a regular self-proclaimed Gentoo power user, I call the litany I got (yeah, I get the same endless, nonsensical bullshit with single packages as well) a fiasco from the user standpoint: where the heck do you start, huh? Ah, of course *you* [might] know.

Not only you but also the devs behind Gentoo have to admit however there are users who feel lost before that [...] <I'm lost for words calling it>. Gentoo might be as robust, well done developer-wise, it has a *user* interface problem and a terrible one — despite your claims — when it comes at problems like the one I reported in my post. And no, it's not located before *my* keyboard and *my* chair.

I hope you can understand thousands of lines, which in my case represent more than the actual number of installed packages — good ol' C behaviour when you miss a semi-colon in the way, see what I mean? — are a catastrophic interface failure for I can't make myself clearer.

[mv]

And no, it's not located before *my* keyboard and *my* chair.

How do you come to that claim?
First of all, not syncing for 100 days is calling for trouble, and if you are a power user as you claim you should know this very well and you should know that it lies in the nature of things: Rather likely, a lot of conflicts have arised, and if portage cannot solve them, it can also not give any hints (because otherwise portage could solve them).
Moreover, it seems besides ranting you did not try to solve your problem. Why did you not ask for any help, if you cannot solve the problem by yourself?
Why did you not follow any of the suggestions which were given to you in your rant (despite you certainly met the wrong tone if you wanted any help)?

Did you even try increasing the --backtrack value so that portage has a realistic chance to solve such a lot of conflicts?

Edit: I am not familiar with the portage resolver, but I would guess that for every "level of implicity" of setting USE you need at least one --backtrack valiue higher.
Of course, such a high value would be a completely unreasonable default for portage, because each value higher will (very roughly speaking) double portage's time for resolving.
Moreover, this is a one-time issue: Once you have solved those many conflicts (by enabling several dozens 32 bit flags), later packages added are unlikely to cause such a deep proceeding in the tree to find the correct switch.

That's why the solution suggested to you (to enable first all 32 flags for multilib packages) was a very good one (if a higher --backtrack value alone does not help or takes too long): Very likely it would lower the required "level of implicity" dramatically (and perhaps even solve all conflicts automatically). After this you can still check systematically which of these flags you want to have enabled.
In addition, if you had followed that suggestion, if there are still some further conflicts (besides the ones solved with the suggestoin), you would have seen these ones instead of all the other ones which portage perhaps eventually might have resolved.

[Roman_Gruber]

Kde 3 is gone. Was kinda useable and windows like. Kde4 is just bloated like hell. Heavily RAM usage and only for powerful boxes in my opinion

gnome 2 is also gone. Was much lighter and leaner. Quite useable until they ditched it for gnome 3. gnome 2 was forked into mate. but thats also not really small anymore ... http://ubuntuforums.org/showthread.php?p=11333073. Gnome3 uses new backbone which is called systemd, and that eats up mayor components. Which makes it harder for other desctop environments to survive. ether they adapt or need to find other ways... Afaik kde4 also started to integrade systemd.

gentoo is one of the few where you can choose systemd / eudev / static init ...

I would not bother with linux mint, which is ubuntu, which is kinda debian afaik, i updated last time my box. It overwrites grub.cfg regardless whats in there. and does not make any backups. and needs endless reboots / can not find mirrors for their tar files / only downloads, than installs, and can only handle one instance of the package manager at all. during hte upgrade i was forced to type around 10 times the password for root to keep the upgrade going. after the upgrade the package manager still told me that some packages should be updated ... those binary distros still suggests a reinstall every 6 months lolz (linux mint ...)

2.6.32 kernels are long gone
3.x.x kernels are on their end, long term support 3.18.x

4. kernel is quite fresh

ext4 is kinda good file system,
reiserfs is kinda gone, was a mess, i had a few file corruption on suse 6.2

staroffice turned into openoffice which turned into libreoffice (seeing it for the free to use, and biggest community, development side)

[davidm]

Kde 3 is gone. Was kinda useable and windows like. Kde4 is just bloated like hell. Heavily RAM usage and only for powerful boxes in my opinion

I'm not sure I agree about kde4 being only for powerful machines. I guess it depends on what you consider powerful. Up until a year and a half ago I used to run kde4 on a p4 with 4GB (~3.2GB usable - x86) of ram. It ran pretty well with no real slowdowns caused by kde4. In fact with a modest Nvidia 8400GS I was even able to watch 1080p HD movies using the VDPAU acceleration and they worked great. Before kde4 I also used more minimalistic WMs including xmonad and stumpWM. The truth is I did not notice much speed difference on that system between them and kde4. The main difference was a bit of memory. Perhaps a couple hundred megabytes maximum difference. I also ran kde4 on that box for a while with only 2GB of RAM and it worked well, but slightly less fast as you would expect.

You didn't mention plasma 5 (unofficially what some call kde5) but on my system 'plasmashell' only uses 230K - 260K of RAM. I can't recall how that compares to kde4 but it's likely about the same. I bet I would still be okay running Plasma 5 on my P4 (if the mobo hadn't died). Plasma 5 is now in the regular ~amd64 portage tree too and can be used without the kde-overlay..

[Fitzcarraldo]

Biggest changes Linux-wise would be the udev monstrosity that has entangled everything.

'Monstrosity' being the operative word. I have grown to dislike udev with a vengeance. It has wasted so much of my time over the last few years, what with the well-intentioned but badly-realised Predictable Network Interface Names, the dropping of firmware loading and the subsumption of udev by systemd. I've just wasted a day trying to decipher the mess that are udev rules files, trying unsuccessfully to make a multi-function peripheral scan via USB interface. The udev design results in a morass of confusing and potentially conflicting rules in umpteen files (potentially in different directories). There is no standardisation in the udev rules files and their contents between different Linux distributions, making investigation and solution of problems even more complicated. Give me strength.

[VinzC]

And no, it's not located before *my* keyboard and *my* chair.

How do you come to that claim?

[...] it seems besides ranting you did not try to solve your problem.

You just made one.

Why did you not ask for any help, if you cannot solve the problem by yourself?

And another one.

Why did you not follow any of the suggestions which were given to you in your rant [...]?

Yet another one.

First of all, not syncing for 100 days is calling for trouble

Ha! I had waited for that one!

So because one hundred days is too much then I shall get troubles. My reward then, right? Erm, no, my sentence, I guess. Thanks, your honour. Shall I go to prison and skip the €1000?

Well, a few hints...?

• In more than a decade, never ever has Portage sucked that much on such a regular basis. To *that* extent, it's become obnoxious.
• Till not so long ago I could have synced and updated after weeks, months, never a problem. Turns out *now* is the biggest I ever had.

Now who decided 100 days was too much, huh? Gentoo council? Devs? You?

Did it occur to you that

• people can leave their home for weeks, months maybe?
• some have a rather demanding job that can require their constant attention for long periods of time — not everyone is a student
• compiling takes *much* time
• not every one has *time* to go through compile every... every what? Is there a standard frequency to apply updates now?
• some like to just breathe a little between updates
• some upgrades might introduce regressions, breakages, incompatibilities... all of this justifying more time to dig the doc, test downgrading, unmasking, re-linking... *Time*
• most people want to just work *with* their system, not *for* it — mind you technology was supposed to free, not enslave Us
• given the [implied] rate at which one is supposed to apply updates *and* Gentoo cannot reasonably advise to do it in an automated fashion, it's clear that it quickly will/has become tedious.

What if I have to leave home for whatever reason, leaving my computer alone for weeks or months? Or if I just don't have *time* to run through all those updates on a more frequent basis? Oh, yes, I know: *I* should switch to a binary distribution, right?

100 days is too long

is just an excuse served on a golden plate — a fallacy for short — to slap users in their face and hide the real problems.

• Why does Gentoo have to compel on forcing updates on a timely fashion *now*?
• Why are breakages, incompatibilities introduced that often?
• Yesteryear months were okay, then it became weeks. Years from now: hours? minutes? How long again until resistance stops being looked down like children just whining and bitchin'?
• Why don't you fellow devs see it a problem to have more information lines than the actual number of installed packages?
• Why can't changes be smooth instead of break massively at once? (Spare me the infamous «update more often and it's gonna be smooth», will you.)

Yesteryear I used to pest against compile-time issues for not having enough trace. I'd rather go through them now as they were *nothing* against that deluge of information. (When I look back, Slackware would look like a breeze to me.) It took me no less than FOUR posts to show only a FRACTION of it! Don't see a problem? There *is* and it is by *design*; Gentoo has *purposefully* evolved to this state.

Gentoo portage [and the compile procedure] is all but an example of stability, given how often dependencies break all of a sudden and massively, requiring users to spent their time going through portage verbosity poop rather than using their system. How would I assume that? Because for the last few updates I ran *every time* through nightmarish days and nights to solve breakages, perl exclusions, masked packages that produce lots more false positive about USE changes, unmask changes, packages incompatibilities... The more you have of this, the less you feel likely to run through them.

Ah sorry, if some prefer to comply and do their sheepish daily updates in perfect, silent obedience, there are others who get their kittens past a certain number of WTF per minute. You wouldn't argue I'm the only one.

Everyone aspires to a certain stability, especially in the long run. Gentoo's late reward has become a constant focus on wasting CPU and time on a compilation frenzy. I've known Gentoo a much, MUCH more quiet companion. I hate it when it starts stepping on my toes demanding of my time for it alone.

I willingly take my responsibilities if I don't fix a security vulnerability and have to chew my bones for having been hit by an internet pest. I can't stand being lessoned by someone who finds normal to constantly run updates with a threat of a system going postal on its user when the reason is maintainers' comfort!

[ct85711]

As much as I don't want to get into this argument, I should point a couple things out...

This issue is not because of Gentoo, it's the nature of the beast; more specifically the upstream projects. Gentoo is not developing all these projects nor maintains them. All the work, and changes is happening upstream, Gentoo is only a middle man providing us a easier way to compile all of the packages. I can tell you easily enough, it doesn't matter what distribution you use. If you compile every dependency by hand and do so for every update afterwards (never using a precompiled binary package, you will run into the same issue here. Using precompiled binaries, you have it easy in that you never have to worry about build time version incompatibilities.

I can tell you since the beginning of Gentoo, and even before, trying to update a old system never was easily. As libraries change, add new capabilities, it ends up breaking old abilities (hence API/ABI changes). These changes are a matter of life in software. It doesn't matter where you look in the computer industry, there may be some backwards compatibilities, but eventually it has to be dropped.

Note: None of this should be considered in anyways an attack on someone, nor directed to anyone.

[mv]

@VinC: Again you are just ranting, completely ignoring the points where a solution to your problem was offered (very likely just using e.g. --backtrack=60 would just have solved your problem completely).

Concerning the 100 days: As ct85711 said: It lies in the nature of things. Every distribution has this problem, but gentoo has the big advantage that you can ease the pain of upgrading by doing this very frequently. If you don't do this, you lose that advantage and will get the pain. It can be sometimes more and sometimes less. Once more: If you are really that power user that you claim to be you should know this. If you didn't have this problem so far, you were extremely lucky and were not there when there were really big changes like passage to grub2/other uefi solution, gpt, gnome3, kde4, udev, gnome2, kde3, gcc4, glibc2, ... (not all of them may be relevant for you, but some certainly were, and they usually caused a lot of pain, especially if you would have had to solve other problems in paralllel to these).
Yes, you can postpone an upgrade, and gentoo still guarantees that there is some upgrade path for a 1 year old system (BTW: A guarantee which causes a lot of pain for the developers), and quite often you can even succeed with much older systems. However, this upgrade path for such old systems is usually never straightforward and usually never tested and usually requires a lot of reading and learning. If you leave your system unmaintained for a long time regularly and are not wliling to learn and accept solutions, gentoo is very likely not the correct distribution for you (for each of these two reasons): There are a lot of distributions out there which require you to do a big update only every few years, and then they hold your hand and install a reasonable default configuration for all of the new things so that you do not have to learn anything, if you accept the defaults. (The disadvantage being that you get even more pain every few years if you do want customization). Gentoo has (and always had) quite the opposite aims: To make it possible to frequently update and customize, both with relatively low pain.

I do not comment the rest of your arguments: Even 1000 arguments why the sun shouldn't be yellow would be completely pointless.

[steveL]

Come on guys and stop that nonsensical bs about multilib... Now Gentoo has a proper multilib support without the old emul hacks which were flawed in every aspect especially for users who were using ~arch who did get older binary which caused multiple no trivial issues, not less. Indeed, for those that have some X, opengl, gtk, alsa, jack related multilib packages... would have to handle somes lines in packages.use. Just accept the auto-write option and then edit the result by trimming the packages version and maybe slot and the comments with a sed command to get somthing quicky workable without *too* much hassle.

And you are calling it a fiasco? What are you calling the old emulation libries then? Indeed, it could be more easier on the users... hoever, use flags shall be enabled for each package--nothing new here, it's just the default behaviour of portage here.

Why don't you just ask directly what is meant? Not that I haven't gone over the basics several times before.

You do not need to set ABI_X86 yoursel because this is the job of the profile.

Make your mind up; above it's set the flags on each package, now it's let the profile set it on all of them for you.

So, yes, proper multilib support in Gentoo which is a big change

"proper" is a matter of conjecture, since you're not interested in how it could be done better, only in ranting about "bs" with nothing to back it up.

Moreover, this is a one-time issue: Once you have solved those many conflicts (by enabling several dozens 32 bit flags), later packages added are unlikely to cause such a deep proceeding in the tree to find the correct switch.

That's why the solution suggested to you (to enable first all 32 flags for multilib packages) was a very good one

You're presenting the same dichotomy as if they were one "solution" as well. And it's not, that's an awful suggestion afaic.
In effect you're building every package that could possibly support the 32-bit ABI, with the extra ABI, even when it's not needed.

And you want to complain that a proper solution requires too much building of stuff that doesn't need it. Yeah right.

[steveL]

Biggest changes Linux-wise would be the udev monstrosity that has entangled everything.

'Monstrosity' being the operative word. I have grown to dislike udev with a vengeance. It has wasted so much of my time over the last few years, what with the well-intentioned but badly-realised Predictable Network Interface Names, the dropping of firmware loading and the subsumption of udev by systemd. I've just wasted a day trying to decipher the mess that are udev rules files, trying unsuccessfully to make a multi-function peripheral scan via USB interface. The udev design results in a morass of confusing and potentially conflicting rules in umpteen files (potentially in different directories). There is no standardisation in the udev rules files and their contents between different Linux distributions, making investigation and solution of problems even more complicated.

Yeah where to begin? The configuration files scattered all over the machine, with some insane poeterring rationale, when serious net admins inform me that's down to RedHat having no equivalent to etc-update (originally a debian utility.) So for that, every other distro has to get in line and use a shitty conception of how to set things up.

Amateur-hour "fixes" to races that as "serious kernel coders" we should all submit to (despite the fact that they're really kernel rejects and a documentation guy) one might have thought they'd have spotted in advance, and an awful lack of testing with the users it's supposedly aimed at; in fact no testing of their own either, before they push it to those. Just dump it on the users and let the distros sort out our bugs for us.
And what a stinker of a "fix", made worse by the desire to stop anyone using anything else, so let's change how you stop it fscking up your network interfaces, and pretend that it's a kernel config (so don't argue) even though it's nothing of the sort.

"Amateur" doesn't begin to cover it. All we get is pretext after bulshytt pretext, while they make up the next round of lunacy that everyone has to argue with, all the while talking down to coders who have more nous and experience in their little finger than these dumbasses are ever going to get to in their whole careers.

FGS, somebody promote these numpties outta the way, if you haven't got the balls to simply stand up to them.

[mv]

That's why the solution suggested to you (to enable first all 32 flags for multilib packages) was a very good one

You're presenting the same dichotomy as if they were one "solution" as well. And it's not, that's an awful suggestion afaic.

How often do I have to repeat and everybody ignores: Of course, the first thing one attempts is to increase --backtrack.
If this does not help, setting the flags as suggested will make all the posted errors vanish, and one can look for the real cause of the problem (if there should be some).
However, this is obviously not a support thread for VinzC's problem - he appears not even to be interested in finding a solution.

In effect you're building every package that could possibly support the 32-bit ABI, with the extra ABI, even when it's not needed.

Yes, when you build it instead of using this configuration only as a tool to locate the real problem (if --backtrack is not sufficient), you would have this disadvantage.
Again: It is not necessary (and so I did not care) to discuss the best solution in detail, since this is not a support thread for VinzC's problem. If it were, I would have written more details and also thought more seriously about the "best" solution strategy. For the sake of this discussion it was sufficient to sketch that there are solutions to this problem, and (although one can discuss about their quality) neither is insanely hard to find, one even being mentioned before this thread already.

Edit:

And you want to complain that a proper solution requires too much building of stuff that doesn't need it.

The difference is that one is a one-shot thing for a particular system and a particular purpose (which - even if "hackishly" compiled once to get a "quick" solution - can easily been undone later, when the user has time and nerve for it), while the other is a permanent overhead for all users and all systems.

[mv]

FGS, somebody promote these numpties outta the way, if you haven't got the balls to simply stand up to them.

Why should somebody (= their employer) do this? They do their job of creating a vendor lock-in pretty well, despite all of the efforts of free programmers to prevent it.
What I really don't get is why Ubuntu has fallen to them: Ubuntu was probably the only distribution with enough resources to patch so many upstream projects regularly to avoid the lock-in. (And then eventually Debian might inherit from Ubuntu... but I begin to dream)

[VinzC]

@VinC: Again you are just ranting, completely ignoring the points where a solution to your problem was offered (very likely just using e.g. --backtrack=60 would just have solved your problem completely).

And you've totally missed my point.

Concerning the 100 days: As ct85711 said: It lies in the nature of things. Every distribution has this problem

Fallacy #1: argumentum ad numerum.

But you don't seem to have perceived what the problem *I* am talking about is. It's not about breaking dependencies. It's not about being forced to recompile a whole bunch of packages. It's two-fold:

1. it's about the way those breakages are pushed to the user: using a verbal poop from the package manager.
2. it's about considering frequent updates is a requirement, optionally accompanied with a threat of "running into troubles" if the user doesn't comply. First point of yours.

And yes, I have read your argumentation about --backtrack=60. Your logic is just flawed.

Do you think everyone actually *needs* all the verbal diarrhoea from Portage? Too much information kills the message. Eventually the users' patience, too. So if too much information is a nuisance and since --backtrack=60 makes such sense then why the heck not have it set to a reasonable value by default and warn when the number of warnings exceeds that value, hmm? EIX does that:

Code: Select all

Found 167 matches.
Only 50 matches displayed on terminal.
Set EIX_LIMIT=0 to show all matches.

Now *that* is good coding, Kudos guys!

Know what? Had --backtrack=60 been the default I wouldn't even have ranted in the first place! Did you actually get that? I'm not hypocritically putting the blame on Gentoo developers for my frustration, no. I'm just saying that making the wrong decision — i.e. not to limit the number of backtrack to a reasonable default — has terrible consequences on usability. In this case, had --backtrack=60 been set by default, no usability nightmare, everything is in sight and the user focuses on the real issues: fixing breakages.

Now tell me: am I really just ranting or making a valid point?

And I don't even agree with the argumentation "every distribution has that problem". If the problem in question is breakages, I agree. But that was *not* my point. See above. Some stepped releases even leave the user with enough time to consider an upgrade or, if all else fails, reinstalling. CentOS has been pretty much stable, as per my experience. So the problem has been taken into account upstream, by the maintainers. Granted, to some extent, *we*, users are also part of that maintenance business.

Whatever.

If you are really that power user that you claim to be you should know this.

Fallacy #2: argumentum ad hominem. Let's see why.

If you didn't have this problem so far

Flawed logic again, I never said that. I've actually had them. All of them.

you were extremely lucky

No. Actually managed them. *All* of them. Took some time and reflection but been through. Proudly. Hence self-proclaimed Power User. See now how your logic is reversed?

FYI: I use extlinux, not Grub nor Grub2. I don't use kde, gnome, gpt. Only gtk and glibc apply from your list. Did I tell you I prefer to stay as clear of troubles as can be? Doesn't mean I flee. But I prefer less to more, especially when more was due to bad design practices out of my control.

Yes, you can postpone an upgrade, and gentoo still guarantees that there is some upgrade path for a 1 year old system (BTW: A guarantee which causes a lot of pain for the developers), and quite often you can even succeed with much older systems. However, this upgrade path for such old systems is usually never straightforward and usually never tested and usually requires a lot of reading and learning.

Amen to that and Kudos then. But let's not forget that's not my initial point. Thanks to the devs though for *that* effort. I know I'll remember the one year limit. Never considered staying inactive that long but even then, thanks.

If you leave your system unmaintained for a long time regularly and are not willing to learn and accept solutions[...]

Ooh, a nice ad hominem fallacy again doubled with #3 cherry picking . Does my [righteous] insistence prove I'm not willing to learn? Why righteous? Look, you don't know me. I'm passing for someone very tolerant. Not many things bother me in general and I accept a lot others would immediately voice against loudly. My friends say of me I'm of good composition and if I open my mouth then I must have damn good reasons to. They listen to me, don't necessarily agree but I'm heard. So unwilling to learn? Unlikely. But you of course can deny that.

gentoo has the big advantage that you can ease the pain of upgrading by doing this very frequently. If you don't do this, you lose that advantage and will get the pain.

That's flawed logic again: turning a requirement into an advantage to plead in favour of frequent updates, which was your point against my rant — confirmed righteous lately — against bad coding practice that impede the user experience. Your assertion is biased because it's not a reasonable choice left to the user since not sticking to the policy is troublesome. I wouldn't call it an advantage rather than a compelling option («Upgrade frequently or else...)

[...]Even 1000 arguments why the sun shouldn't be yellow would be completely pointless.

Now *that* is gross. Fallacy #4: Reductio ad absurdum, trying to make a fool of myself using inappropriate comparison. Gentoo is the way it is based upon developers and maintainers decisions and actions. What about the Sun? Unless Gentoo devs are God (in which case, I'm soooo sorry). Allow me to keep a reasonable doubt on the latter. Not even proved that the Sun was written by God. Not even a clue there is a God at all.

However, this is obviously not a support thread for VinzC's problem - he appears not even to be interested in finding a solution.

Ad hominem attack. Again. #5. You start to cumulate.

Whatever.

I was sincerely hoping you'd got my [rant] point now and you'd stay clear from pointing at the excuse of frequent upgrades. But now I have a doubt.

Okay, you've addressed several of my points in my reply to your comments. But again, my questions here weren't the point rather than a list of things to consider before smashing anyone with that argument. Besides that very point drifted from the most important: Portage should shut up past a certain amount of information, keeping the user informed there are more messages waiting. Get back to my example with EIX.

I agree that's much ado for nothing but even though my rant is a litany in itself, it shall illustrate why it's important to spare the user the burden of filtering [useless] crap. There *must* be a default for --backtrack and definitely not in favour of showing everything unconditionally.

Too much verbosity *is* the problem. Infrequent updates not that much (I can cope with that, always had). Troubles due to the latter just top the nausea given by the former, that one is unacceptable.

This would have been immensely preferable:

Code: Select all

   (dev-libs/libgpg-error-1.13:0/0::gentoo, ebuild scheduled for merge) pulled in by
    dev-libs/libgpg-error required by (net-libs/gtk-vnc-0.5.4:0/0::gentoo, ebuild scheduled for merge)
    >=dev-libs/libgpg-error-1.11 required by (app-crypt/gnupg-2.0.26-r3:0/0::gentoo, installed)
    >=dev-libs/libgpg-error-1.8 required by (dev-libs/libassuan-2.1.1:0/0::gentoo, installed)
    >=dev-libs/libgpg-error-1.8 required by (dev-libs/libksba-1.3.3:0/0::gentoo, ebuild scheduled for merge)
    >=dev-libs/libgpg-error-1.12[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_ppc_32(-)?,abi_ppc_64(-)?,abi_s390_32(-)?,abi_s390_64(-)?] (>=dev-libs/libgpg-error-1.12[abi_x86_32(-),abi_x86_64(-)]) required by (dev-libs/libgcrypt-1.6.3-r3:0/20::gentoo, ebuild scheduled for merge)

  (dev-libs/libevdev-1.3:0/0::gentoo, ebuild scheduled for merge) pulled in by
    dev-libs/libevdev required by (x11-drivers/xf86-input-evdev-2.9.1:0/0::gentoo, installed) 

... 2365 similar errors. Please run emerge with --backtrack=0 to see them all.

It's a nice tip to trick the user into learning about the --backtrack thing and, if he's curious, makes him realize to what extent Portage damn rocks! as he runs emerge with --backtrack=0. Two birds with one stone.

For the sake of this discussion it was sufficient to sketch that there are solutions to this problem, and (although one can discuss about their quality) neither is insanely hard to find, one even being mentioned before this thread already.

And [post=7775636]Xavier Miller[/post] was extremely kind to hint at crucial details I missed in trouble shooting the ABI issue. Should have thanked him right away but again, that's not the point as I detailed multiple times. So please, don't stick to that any further as you're proving multiple times you're missing the real issue.

[ct85711]

But you don't seem to have perceived what the problem *I* am talking about is. It's not about breaking dependencies. It's not about being forced to recompile a whole bunch of packages. It's two-fold:

it's about the way those breakages are pushed to the user: using a verbal poop from the package manager.
it's about considering frequent updates is a requirement, optionally accompanied with a threat of "running into troubles" if the user doesn't comply. First point of yours.

Ok, your still thinking that Gentoo is pushing these breakages and frequent update stuff, and that is completely WRONG! Gentoo is NOT maintaining any of the packages, it's all of upstream that is pushing these frequent updates! Gentoo is only organizing it for you, that is it! They don't control any of these updates, Gentoo is only a middleman giving you want upstream is handing out.

The only breakage that is from Gentoo directly, that I know of, is the multilib ABI. Even on that, there is no clean/nice way on dishing that out without forcing everyone to reinstall their systems. I'd bet we all would be glad to be enlightened if you know of how to update every system so that every package has a 32 bit and a 64bit installed at the same time and keep everything organized.

And I don't even agree with the argumentation "every distribution has that problem". If the problem in question is breakages, I agree. But that was *not* my point. See above. Some stepped releases even leave the user with enough time to consider an upgrade or, if all else fails, reinstalling. CentOS has been pretty much stable, as per my experience. So the problem has been taken into account upstream, by the maintainers. Granted, to some extent, *we*, users are also part of that maintenance business.

You are not paying attention that Gentoo has NO RELEASES, all Gentoo is doing is directing you to where you download the packages. Gentoo has ALWAYS been classified as a rolling update distribution. That means that the updates are continually updated with no stop points for a release.

If you think updating a old system should be easy, you try it! I dare you to try updating a old system to the newest version by compiling everything yourself without using any precompiled binaries. I have done this myself for over 4 years, so I know how it is and I will tell you using Gentoo is a h@ll a lot easier.

Note: I did it while I used Redhat 2 distro and compiled everything (entire toolchain, kernel, everything myself).

[VinzC]

@ct85711,

You are picking off-topic comments I made to mv's replies to my rant and I hope you realize that.

By "how changes are pushed to the user" I actually mean "how the package manager totally hinders the list of packages because of too much verbosity so that the default backtrace has the terminal backlog overflown". Nothing more. This very point, i.e. backtrace default value, is Gentoo dev's responsibility, not mine.

So I am not

• thinking Gentoo is pushing packages to the user (it's a wrong interpretation of my litany)
• talking about breakages, please, I made that sufficiently clear repeatedly mentioning breakages were not the point of my rant, didn't I? So why still obsessing with that off-topic, wrong interpretation of my argumentation. Besides, I said I disagreed with your point that every distribution has the same problem; I didn't say you were wrong.

Heck, am I supposed to explain in details every single word I pick in every single sentence I write to prevent misinterpretation?

So, to the risk of repeating myself again, my point, i.e. the problem I'm referring to is:

the current behaviour of emerge as for the default value for --backtrace is such that it poses a usability issue, i.e. insanely too much verbosity, which prevents focusing on the list of packages to emerge! Period.

EDIT: Rephrased, looks like --backtrace might be not the right target...

the current behaviour of emerge provides no default limit to the number of additional information such that it poses a usability issue, i.e. insanely too much verbosity, which prevents focusing on the list of packages to emerge!

Eventually, what pisses me off is that, instead of acknowledging that problem, someone out of the blue lessons me on the fact that delaying updates is calling for troubles! I know that and have been knowing that for years. Moreover this is no way to answer the underlying usability problem I ranted about!

Anything else has nothing to do with my rant and is pure speculation on my personality (you're not in my head either to even allude to what I might think or believe), I hope I am making myself crystal on that.

I mentioned stepped releases only to make the point that some distributions delay the upgrade process until the next big release, hence the breakage problem is not continuous (as in rolling releases such as Gentoo) but delayed to the end of the release life at least. As a result this spares the user the burden of ultimately having to reinstall everything. It doesn't mean I ignore what Gentoo is. It doesn't mean I want Gentoo to be a stepped release. It means nothing else than just an illustration how other distributions *delay* the trouble, in spite of being pre-compiled, which, again, I am well aware of.

Neither do I mean upgrades should be easy. I precisely don't since, if you re-read my post, you'll find

I can cope with [infrequent updates], always had

implying I can cope with the burden of infrequent updates.

What lead you to the deductions you made about me is beyond my understanding. But well...

[steveL]

@VinzC: you have my sympathies; arguing with someone else's circular reasoning, only gets you caught up in ever-decreasing circles. ;-)

Bear in mind though, that trolls typically prefer it when you do most of the talking, and they simply poke from time to time for that reaction.

Rise above it, ignore them and move on. :-)

[VinzC]

@VinzC: you have my sympathies; arguing with someone else's circular reasoning, only gets you caught up in ever-decreasing circles.

Bear in mind though, that trolls typically prefer it when you do most of the talking, and they simply poke from time to time for that reaction.

Rise above it, ignore them and move on.

Words of wisdom Steve. Looks like I have too much faith in pragmatism sometimes. Thanks for your sympathy. Be sure I do really appreciate that.

[mv]

@VinzC: First a hint: When you try to appear smart by trying to "exhibit" rhetorical tricks, do this only when such tricks are actually used, or if at least if your claims make any sense.
Do not claim an "argumentum ad numerum" "fallacy" when the given reason is "it lies in the nature of things".
Do not call "reductio ad absurdum" a "fallacy" only because it correctly showed the absurdity of your arguments (to require something impossible).
Do not attack somebody of an "ad honmenem" "fallacy" if you start to introduce yourself as a power user for whom it is impossible that the problem lies between his chair and keyboard (and making this introduction even worse by simultaneously proving that the problem actually does lie there and continue your attacks until people prove it to you.)
Try to understand the structure of the sentence ("if ... then ...") before falsely interpreting the condition of a logical implication as a claim (What has "cherry picking" to do with this, anyway? Of course, every time I show that some claim of your is false, you can call this "cherry picking", even if I show it for every single claim...)
And BTW: This is not a support thread for you. If you want support, open a topic or at least ask your question in a friendly manner. (Although I am not sure whether I would be replying to you given the tone you have shown here).

Anyway, for the other readers, I think that I should correct at least some of your wrong technical claims/misunderstanding.

CentOS has been pretty much stable, as per my experience

Completely irrelevant. It seems you completely failed to understand my comments how binary distributions solve this problem, in which all distributions run into in principle. (If you find a way how to avoid it: Great, publish it! You will be the hero of everybody!)
If you prefer this type of solution (practically complete reinstall after some period of time) you should (in fact: must) switch to a binary non-rolling distribution. Nobody claimed that this must be a bad thing or go with instability.

it's about the way those breakages are pushed to the user: using a verbal poop from the package manager.[...]
I have read your argumentation about --backtrack=60. Your logic is just flawed.

I think I had written this only in another thread, therefore I repeat this fact: Solving dependencies is an NP-complete problem. This means that it is (practically) impossible to solve it unless only very few choices have to be made.
Also here: It lies in the nature of things; if you know a way how to solve this problem, publish it: It is one of the unsolved millenium problems.
Until somebody solves it, we can consider this problem as unsolvable in principle.
In practice this means that if portage is not able to solve this problem (e.g. beacuse the backtrack value is too low), portage cannot provide useful information how to solve it. So giving all collissions is the best which portage can do.
In fact, this information helped in your case to understand that for a lot of packages the abi_x86_32 is related with the problem (and therefore the alternative solution could be given to you if --backtrack does not help).

Had --backtrack=60 been the default I wouldn't even have ranted in the first place

Not for this reason, but then this default could very well be the reason: A high backtrack value has two major disadvantages. First of all, it means that portage, as a rule, needs much longer for resolving dependencies. I am not speaking about a factor 2 or 3 or even 20: The value --backtrack=60 means that it can neeed about 2^60 times as long - practically forever. (Whether it actually needs that long depends on many things, but actually it can mean that for some users portage will just never work.)
But not only this. (Again, I do not know the details of the algorithm, but I would be very surprised if the following is false.) With a high --backtrack value, chances are good that portage finds some solution of a complicated dependency setting. However, chances are lowered that portage finds the "best" solution (which requires the least changes) which is usually what the user wants.
You were in the very special situation that many dependencies had changed: For this exceptional situation the setting of a high --backtrack is appropriate. In general, it is not: In most situation a low default is better.

This would have been immensely preferable:

Code: Select all

... 2365 similar errors. Please run emerge with --backtrack=0 to see them all.

I don't agree at all. It could be that by accident just the most misleading error is output: With the current output, one could at least guess that the abi_x86_32 USE-flag is related. In the worst case - when one could not observe any joint features in the errors and could not make head and foot of any other error - it did not hurt to output the additional information: It is left to the user whether he ignores it or not.