Alan McKinnon <alan.mckin...@gmail.com> writes: > On 20/09/2015 17:28, lee wrote: >> Neil Bothwick <n...@digimed.co.uk> writes: >> >>> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
> [...] >>>> !!! Multiple package instances within a single package slot have been >>>> pulled !!! into the dependency graph, resulting in a slot conflict: > [...] >>> These are unimportant, it is simply portage telling you it is not >>> updating some packages to the latest available and why. Personally, I >>> believe this sort of output should only be shown when using --verbose. >> > [...] >> Should I always ignore such messages? > > No, you should not ignore such messages. They are printed for a reason. Well, what can I do other than ignore them? With dependencies as they are, and given that I don't want to remove packages, some of the packages that could be upgraded to newer versions won't be upgraded because otherwise things might be broken. There's nothing I could do about that, or is there? > You have a SLOT conflict and whether that prevents you from proceeding > or not doesn't change the fact that portage knows you have that conflict. Is it possible to solve this conflict without removing packages? > In your specific case today, I believe portage will simply install the > lesser version and be done with it, but it will only do that when you > fix the USE issue (a whole separate issue) Probably --- yet it tells me about conflicts, makes them appear to be important, and leaves me wondering how to solve them. > [...] > The USE conflict for sure. Maybe the SLOT conflict but I think portage > will just deal with that one > [...] >> This one doesn't look very important, or does it? > > Chill dude, seriously. The sky is not about to fall on your head and the > bits on your disk are not going to miraculously re-arrange themselves > into Windows just because you can't do this update. Sure, yet why make unimportant messages look important and important ones unimportant? > Portage is what it is, deal with it. > > The portage team are all unpaid volunteers just liek everyone else and > none of us have any right at all to make demands of them. Especially not > you and I who are not active contribution solutions. I know --- however, making a suggestion to improve the messages is a contribution. > [...] >> How about adding comments to such messages, like "You don't need to do >> anything to be able to proceed." and "You need to fix this before you >> could proceed."? > > If emerge exited then you need to fix something in your config. > If emerge does not exit then your config can be used as-is. Messages more helpful could make it easier to figure out what needs to be fixed. > [...] >> The last sync I did before the one yesterday wasn't the day before >> yesterday but over three months ago, so don't ask me today (or next >> weekend or whenever I give it another try) when that exactly was. See >> what I mean? Asking me to mask all packages to a certain point in time >> is like asking me to do much of the package management by myself. > > Exactly. You DO need to do the package management yourself. The Gentoo > devs provide useful tools in the form of portage and the tree with it's > ebuilds and eclasses, plus some amazing automation. > > But, are here's the bit where so many people move away from Gentoo: > > You are required to do the management yourself, including most of the > thinking and all of the sweeping up of broken pieces. That's what you > signed up for when using Gentoo. Perhaps not so many people would move away if the messages were improved. > If you want to roll back the tree, then you need to implement a > solution that will let you do it as Gentoo does nto provide one. Git > now makes this easier. Converting to btrfs might work for that, if I can boot from it. > However, tree rollbacks are inadvisable for excellent technical reasons > - see if you can figure them out. Better to snapshot your entire system > and revert the snapshot if it goes south. That's not even advisable with sources, though IIRC, the reasons for that might not apply here. However, it's weird that a system like git makes it inadvisable to undo something, considering that being able to undo something very easily, is one important reason to invent and use such a system in the first place. Using snapshots for undoing things git is quite an application of overengineering. -- Again we must be afraid of speaking of daemons for fear that daemons might swallow us. Finally, this fear has become reasonable.
