Alan McKinnon <alan.mckin...@gmail.com> writes: > On 26/09/2015 11:47, lee wrote: >> Rich Freeman <ri...@gentoo.org> writes: >> >>> On Sat, Sep 19, 2015 at 3:57 PM, Alan McKinnon <alan.mckin...@gmail.com> >>> wrote:
> [...] >> It gives the same results (after syncing again), plus a message that >> wasn't there before: >> >> >> ,---- >> | x11-drivers/nvidia-drivers:0 >> | >> | (x11-drivers/nvidia-drivers-355.11:0/0::gentoo, ebuild scheduled for >> merge) pulled in by >> | (no parents that aren't satisfied by other packages in this slot) >> | >> | (x11-drivers/nvidia-drivers-340.93:0/0::gentoo, ebuild scheduled for >> merge) pulled in by >> | ~x11-drivers/nvidia-drivers-340.93 required by >> (media-video/nvidia-settings-340.58:0/0::gentoo, ebuild scheduled for merge) >> | ^ ^^^^^^ >> `---- >> >> >> This looks kinda weird because I expect those drivers to be updated as >> well, and if they aren't, I will have to remove nvidia-settings. >> >> Let's try backtrack 500 ... same result, and doesn't take longer. > > That doesn't look like a block. It looks like an info message that > portage is "helpfully" displaying (but really belongs only in -v output. > Maybe even the non-existent -vvv...) > > Portage is telling you *why* it is not updating to latest stable > nvidia-drivers even though a higher version is in the tree. It's because > nvidia-settings is out of step with nvidia-drivers. Look at output of > "eix nvidia": > > nvidia-drivers-355.11 is stable > nvidia-settings-355.11 is unstable. > > The driver package will update to 355.11 when the settings package goes > stable. > > A related question is "do you really need the latest nvidia drivers, or > is 340.93 still good enough? It was good enough for the entire time you > had it installed." Do I need to update at all? After all, the system has been running fine all the time, except that I wanted the latest version of seamonkey and that I tend to update every three months or so as time permits, and the last update was almost haft a year ago or so. Of course I want the latest nvidia drivers, so I removed nvidia-settings. (I have updated, and it took almost 2 days.) Nvidia-settings is kinda weird anyway, like when you enable sync to vblanc, apparently that is somehow being remembered, and the question is "when is it applied": When you start an X session or when you start nvidia-settings. Same goes for all the other settings you can make with it. And now, with nvidia drivers incompatible with nvidia-settings and nvidia-settings not installed, what settings that have been made with it are applied? >>> If it is the rdepend issue then you can probably emerge -1 librevenge >>> and whatever else is depending on the old version to fix it. >>> >>> Also, emerge running --changed-deps=y from time to time may make those >>> kinds of problems less likely. The first time you do it prepare to >>> see a LOT of stuff get rebuilt - any of those packages could cause >>> issues in the future but most probably will not. >> >> Good to know, I'll keep that in mind. I tried it and it's not too much >> to rebuild, only a bit surprising: > [...] >> >> Should I do that before updating or after? I guess I'm on the save side >> doing it before, so I'll do that. > > Before, or just include the option in your emerge command. Portage will > sort out the order to build them in. Ok --- I did it before and after ... > Remember something about portage - the only source of info it has about > packages is what is in ebuilds. So if say a package from upstream now > needs a different version of automake to build correctly, and the dev > forgot to add that[1], portage can't take account of it and can't help. > > Portage also has many useful shortcuts, things like "you don't need to > rebuild that package just yet as nothing in the current list needs it > yet" so there are options to leave those packages out. But if "nothing > needs it yet" is not true because it's missing from ebuilds, you run > into a mess. > > And the really important thing is, portage cannot help resolve this. > It's dumb software and has no clue why that build is failing. Isn't that the same for all package management software? >>>> You fail to understand how gentoo works. At no time did Gentoo ever >>>> guarantee that updates would work like binary distros and the process >>>> would be trouble free. Quite the opposite - Gentoo is upfront in telling >>>> you that there will always be update issues and you are the person to >>>> solve them. >>>> >>> >>> While Gentoo doesn't do as much handholding as many distros, the >>> portage output above should not be viewed as something we are proud >>> of. >> >> At least I'm learning here :) > > Good for you. Learning is always hard. Some years ago I found out that the learning isn't the problem when I was like "I don't want to do this (because I need to learn it)" and then did and learned it. The problem is bringing oneself to do it. > Success has a small learning potential; failure has huge learning > potential. And with computing the most valuable lesson is often what not > to do. Not really: You end up learning so much about what not to do that you can't do anything anymore because you have learned not to do it. If you don't experiment sufficiently and don't allow yourself to fail, you get stuck and become unable to extend your limits. Success is required for without it, you won't make any progress and give up eventually. A failure can be a success, depending on your approach. >>> --backtrack fixes a lot of issues, and there aren't a lot of simple >>> solutions for that without slowing down emerge. >>> >>> On the other hand, a lot of the runtime dependency issues could be >>> fixed. There is a discussion on -dev right now about getting rid of >>> dynamic runtime deps, which would probably help cut down on some of >>> the more bizarre behavior. >> >> Making the output "nicer" --- i. e. more informative --- might go a long >> way towards more handholding without slowing things down. If emerge >> would tell me "you can ignore this (and look for a solution later if you >> like)" and "you need to fix this before you can proceed", I could be >> straightforward by updating and looking into fixing things that bother >> me eventually. The system would still work fine, or better than before, >> after the upgrade, which is the most important issue to begin with. > > There's a huge problem with that. > > Seems to me you are thinking like a human (because you are one) and not > seeing portage's limits. Portage has no idea what would solve the issue > so can't give any recommendations worth a damn. The best it can do is > print some hardcoded logic that looks like it might apply. According to that, the human is even less able to figure out what might solve the problem than portage is: The human doesn't know anything about the huge number of dependencies involved, and even if they did, it would take them really really long to go through all of them to figure out anything at all. Now if they do it right, the human would come to the same conclusion as portage, provided that portage does it right. > For instance, say you have two packages A and B, and both have USE flag > Z. On your system you have A build with Z and B built without Z. After a > sync, the latest ebuild for A says that is Z is enabled, then it > requires Z also be enabled in B. > > Portage is not going to just change your USE preferences so it tells you > "dude, you need to disable Z for A, or enable it for B. I can't continue > till you fix that". Portage can tell you this because the data fits a > standard pattern. That's the same thing the human would figure out. > Ah, but those things are rare. The real world we live in is much more > complicated than the exact thing in your PC's RAM - problems are more > like cyclic deps that conflict, and portage does not know what you want. > > Instead it just dumps a crap load of related output and tells you to > figure it out, because it can't. > > Binary distros get around this problem by removing your choice, so the > problem never happens there. That wasn't at all my point. I don't expect portage to figure out what a human cannot figure out. I don't expect portage to make a decision a human needs to make. All I'm saying is, make it easier for the human to figure out what portage has figured out by providing the human with better messages. I'm sure portage does "know" which things *must* be "fixed" by a human decision (like the USE flags) and which ones need not be fixed by human decision. So it could just tell the human, as I suggested, either: "you must fix this" or "you my ignore this". >From there, the human can figure out what they need to fix and go from there. That's what I did in this case, and guess what, there were no slot conflicts after fixing the USE flags. >> The software would be updated to the best achievable point then. > > Err, that's exactly what portage already does. In the absence of errors, > it updates what it can. Some errors are considered serious enough, with > enough possible side-effects, that portage will not continue with a full > update till you fix them. You can often get around this by emerging > individual packages instead of everything using world Then why should it be such a huge problem to have portage tell us what we need to fix in the first place? Let us humans fix just that and try again and see what happens, breaking down the problem into more manageable steps. That would suit both the human and the computer. >> That's >> like getting it 95%+ perfect with 0% effort from the user, and that's >> pretty darn good. The last 5% usually take 200% of the effort. In this >> case, it's impossible to get past 96.5% because the remaining 3.5% >> inevitably must be decided by the user. And if the users didn't have >> their choices and their powers of making decisions, they'd become very >> unhappy with Gentoo. > > > Again, that's exactly what portage does. Perhaps you don't see it yet > because portage doesn't pretty-print it's output much. It throws lots of errors, making irrelevant ones appear as most important and most important ones appear as minor. It doesn't take pretty-printing to do it the other way round, or to shut up about irrelevant errors until the most important ones are fixed. > It's been said many times in this thread - the output could be more > useful. What usually goes unsaid is that doing that is insanely, > amazingly, frickingly HARD. The devs are improving portage all the time, > and I'm confident they will improve output when they know how to. Right > now, they probably don't, it's still a question without an answer. > > If you know how to improve it, the devs will happily accept high-quality > patches. Ok, why is that so incredibly hard? Somewhere, there must be a 'print' statement where it says "slot conflict". Add to that that those "can probably be ignored before other problems are fixed" (and remove all these exclamation marks while you are at it), and the human would tend to fix the other errors and the slot conflicts might go away automagically just like they did in this case. If that is too hard, I would have to assume that portage doesn't "know" whether there's a slot conflict or not and be amazed as to how it produces any messages about them. > [1] This is a very easy mistake to make. The dev can easily already have > the new version of automake so stuff just works for him. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
