| View previous topic :: View next topic |
| Author |
Message |
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 193
|
 Posted: Sun Apr 15, 2012 8:02 am Post subject: Fatal fail when emerge can't update to the latest version |
 |
|
I must admit that this is perhaps the 3rd time that I bring this topic up, mostly because it still has not been solved to my satisfaction.
I do have gtk+ in ~amd64
Now, when I emerge -uDN world or even just emerge -u gtk+, portage fatally fails because newer gtk+ in ~amd64 is blocked by my current Xorg-server.
That immediately brings up two questions:
1) Why does portage complain about a block rather than saying something like "keywords required for xorg-server", so that the block would be resolved?
2) Why does this happen at all (which is the topic I've repeatedly brought up)! Portage should just *not* update instead of failing with a fatal error. At best, it may wish to inform me that there is a newer version in ~amd64 which can currently not be updated to. But not in this manner with a fatal error!
With regard to 2), I vaguely recall that this has something to do with autounmask and disabling it, so I would get the behaviour I described - but I can't recall the details. Either way, this inconsitent behaviour of throwing a fatal error should not be the default!
Emerge *should*, in oder to be self-consistent, behave according to the policy:
-u means "update everything to the newest version possible"
which, by definition, makes errors impossible. |
|
| Back to top |
|
 |
genstorm
Advocate
Joined: 05 Apr 2007
Posts: 2238
Location: Austria
|
| Posted: Sun Apr 15, 2012 10:49 am Post subject: |
|
|
What's the emerge output actually?
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic |
|
| Back to top |
|
|
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 193
|
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 7609
|
| Posted: Sun Apr 15, 2012 5:23 pm Post subject: Re: Fatal fail when emerge can't update to the latest versio |
|
|
| ManDay wrote: | | I must admit that this is perhaps the 3rd time that I bring this topic up, mostly because it still has not been solved to my satisfaction. |
How many inadequate answers do we need to give before you give up? 
| ManDay wrote: | | Now, when I emerge -uDN world or even just emerge -u gtk+, portage fatally fails because newer gtk+ in ~amd64 is blocked by my current Xorg-server. |
Do I understand correctly that you have marked x11-libs/gtk+ as ~arch, but have not marked x11-base/xorg-server as ~arch? Mixing stable and unstable can work, but often leaves you in a much less supported configuration than sticking purely with one or the other. Could you provide the output of emerge --info ; cat -n /etc/portage/package.accept_keywords?
| ManDay wrote: |
That immediately brings up two questions:
2) Why does this happen at all (which is the topic I've repeatedly brought up)! Portage should just *not* update instead of failing with a fatal error. At best, it may wish to inform me that there is a newer version in ~amd64 which can currently not be updated to. But not in this manner with a fatal error!
With regard to 2), I vaguely recall that this has something to do with autounmask and disabling it, so I would get the behaviour I described - but I can't recall the details. Either way, this inconsitent behaviour of throwing a fatal error should not be the default!
Emerge *should*, in oder to be self-consistent, behave according to the policy:
-u means "update everything to the newest version possible"
which, by definition, makes errors impossible. |
Under such a policy, how do you propose emerge behave when all newer versions are unavailable? How should this interact with the situation that skipping the update leaves the user with a configuration that is broken, unsupported, or vulnerable to known security problems?
For example, what if there were a security bug in <=x11-libs/fake-package-3.2:3 for which all users need an immediate upgrade and the user has in world a package with RDEPEND="=x11-libs/fake-package-3.0*:3"? Such a user must either skip the security update or remove the package which requires the vulnerable version of fake-package. If I were that user, I would want emerge to throw a fairly obvious and scary error that I need to make a decision about how to proceed. If I do not run with --quiet-build=y or --quiet, then printing a warning and continuing will not necessarily leave the text where I can see it later. |
|
| Back to top |
|
|
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 193
|
| Posted: Sun Apr 15, 2012 7:38 pm Post subject: Re: Fatal fail when emerge can't update to the latest versio |
|
|
| Hu wrote: | | ManDay wrote: | | Now, when I emerge -uDN world or even just emerge -u gtk+, portage fatally fails because newer gtk+ in ~amd64 is blocked by my current Xorg-server. |
Do I understand correctly that you have marked x11-libs/gtk+ as ~arch, but have not marked x11-base/xorg-server as ~arch? |
Yes
| Quote: | | Mixing stable and unstable can work, but often leaves you in a much less supported configuration than sticking purely with one or the other. Could you provide the output of emerge --info ; cat -n /etc/portage/package.accept_keywords? |
What do you mean by "purely one or the other"? Purely ~amd64 system?!
emerge --info
cat -n /etc/portage/package.accept_keywords
| Quote: | | ManDay wrote: |
That immediately brings up two questions:
2) Why does this happen at all (which is the topic I've repeatedly brought up)! Portage should just *not* update instead of failing with a fatal error. At best, it may wish to inform me that there is a newer version in ~amd64 which can currently not be updated to. But not in this manner with a fatal error!
. |
Under such a policy, how do you propose emerge behave when all newer versions are unavailable? |
Do nothing. At most *inform* (warn) the user about more recent, but unreachable versions.
| Quote: | | How should this interact with the situation that skipping the update leaves the user with a configuration that is broken, unsupported, or vulnerable to known security problems? |
Such a version (say, vulnerable) would be removed from portage, running -u will then down/upgrade to the best version possible.
| Quote: | | For example, what if there were a security bug in <=x11-libs/fake-package-3.2:3 for which all users need an immediate upgrade and the user has in world a package with RDEPEND="=x11-libs/fake-package-3.0*:3"? Such a user must either skip the security update or remove the package which requires the vulnerable version of fake-package. If I were that user, I would want emerge to throw a fairly obvious and scary error that I need to make a decision about how to proceed. If I do not run with --quiet-build=y or --quiet, then printing a warning and continuing will not necessarily leave the text where I can see it later. |
In this case you would get an error. The vulnerable version would be removed from portage, hence no longer available. Downgrading will not satisfy fake-package and upgrading is impossible - an impasse which causes an error. |
|
| Back to top |
|
|
castor_fou
Apprentice
Joined: 23 May 2002
Posts: 246
Location: Clermont-Ferrand, France
|
| Posted: Thu Apr 19, 2012 7:30 pm Post subject: |
|
|
Did it in 2 steps (adding appropriate keywords when needed)
| Code: | | emerge -v --oneshot xorg-server nvidia-drivers |
then
|
|
| Back to top |
|
|
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 193
|
| Posted: Sun Apr 22, 2012 8:45 pm Post subject: |
|
|
| castor_fou wrote: | Did it in 2 steps (adding appropriate keywords when needed)
| Code: | | emerge -v --oneshot xorg-server nvidia-drivers |
then
|
What? |
|
| Back to top |
|
|
Jaglover
Advocate
Joined: 29 May 2005
Posts: 3973
Location: Saint Amant, Acadiana
|
| Posted: Sun Apr 22, 2012 10:55 pm Post subject: |
|
|
I just saw your other thread.
Running stable is OK, everything should build as expected.
Running testing is OK, too. If something does not build you should make your contribution and report a bug.
Mixing stable and testing? You are in your own, if builds fail fix it for yourself, do not complain, do not expect support, do not file a bug.
_________________
Please learn how to denote units correctly! |
|
| Back to top |
|
|
ManDay
Apprentice
Joined: 22 Jan 2008
Posts: 193
|
| Posted: Mon Apr 23, 2012 11:33 am Post subject: |
|
|
| I call this nonsense, Jaglover. |
|
| Back to top |
|
|
Hu
Watchman
Joined: 06 Mar 2007
Posts: 7609
|
| Posted: Tue Apr 24, 2012 2:51 am Post subject: |
|
|
| Call it what you like, but the comments from Jaglover could have come from any of the long time forum posters. Mixed branches can often be made to work, but when you get a failure, the first response will usually be to ensure that all the involved packages are from the same branch. |
|
| Back to top |
|
|
kimmie
Guru
Joined: 08 Sep 2004
Posts: 531
Location: Australia
|
| Posted: Tue Apr 24, 2012 6:15 am Post subject: |
|
|
EDIT: Please read follow-ups before responding to this.
From a long-time forum poster who mixes stable and testing: Jaglover's comments oversimplify the situation. Sure, trying to run libpng-1.6 on a stable system is a really bad idea, and if you try a good spanking is the right response. BUT many of us have stable systems with a few top-level packages where we really need the testing (read: upstream stable) version. 99.9% of the time, this works fine. And when it doesn't "do not pass Go, do not collect $200, go directly to jail" isn't at all what has to happen. Support is available on these forums. I've provided it myself. Sometimes the result of sorting out these issues is exactly the input the maintainer needs to get a package stabilised.
Last edited by kimmie on Tue Apr 24, 2012 7:48 am; edited 1 time in total |
|
| Back to top |
|
|
cach0rr0
Moderator
Joined: 13 Nov 2008
Posts: 4117
Location: Houston, Republic of Texas
|
| Posted: Tue Apr 24, 2012 7:16 am Post subject: |
|
|
| kimmie wrote: | | From a long-time forum poster who mixes stable and testing: Jaglover's comments oversimplify the situation. Sure, trying to run libpng-1.6 on a stable system is a really bad idea, and if you try a good spanking is the right response. BUT many of us have stable systems with a few top-level packages where we really need the testing (read: upstream stable) version. 99.9% of the time, this works fine. And when it doesn't "do not pass Go, do not collect $200, go directly to jail" isn't at all what has to happen. Support is available on these forums. I've provided it myself. Sometimes the result of sorting out these issues is exactly the input the maintainer needs to get a package stabilised. |
agree with this for the most part, but that's when the desired end game is $foo package installed successfully
it's a different can of worms when the desired end in a mixed arch/~arch environment is "why is portage doing this? this is wrong!"
from a general QA perspective (in my paid work, mind you, here I'm but a simple human spam filter) QA against all "arch" is sensible, as is QA against all "~arch". It is not, however, sensible to expect QA to test every single permutation of Package A as "arch" combined with Package B that's "~arch".
When mixing the two you do so with an expectation that the setup you are using has not been fully QA'd, and that encountering difficulty with installation is a probability if not an inevitability. What would a commercial software vendor, for example - someone you're actually paying for product and support - tell someone running a setup that hasn't been signed off on by QA? The lazy ones, "you're SOL", the good ones "we'll try to help you make this work, but within reasonable limits". To that same end, it is not a reasonable expectation for that customer to have that the vendor performs QA against a setup that is specifically and strongly advised against up front.
Which brings us back I suppose, to the question of what's reasonable to expect in Gentoo land with regards to running a non-QA'd setup (mixed arch/~arch). People will generally try to help you get things working. But such situations are unlikely to be particularly strong drivers for standard/default/expected behaviour. Furthermore as human bandwidth is finite no matter how large the operation, be it a FOSS project or Ubermegasoftware Corp, expect pushback before recommendations are considered for changing default behaviour, that pushback being "does this happen with a QA'd setup (non-mixed environment)? If so, we'll look into it, if not, we're not changing default behaviour - though we might help you work around it". IMHO it isn't fair to expect the various combinations of keywords among the ~35,000 different packages in Portage to all be tested with every conceivable permutation of each; the math on that for the number of required tests is non-trivial.
NOTE: none of this is to say that combinations of such things don't receive any testing - they do. But as with any vendor, commercial or otherwise, expected behaviour is determined by testing ONLY officially supported, fully QA'd environments.
_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash |
|
| Back to top |
|
|
kimmie
Guru
Joined: 08 Sep 2004
Posts: 531
Location: Australia
|
| Posted: Tue Apr 24, 2012 7:32 am Post subject: |
|
|
Oops, was distracted, now fully back on-topic:
Manday,
You seem to be stuck on a point about the meaning of -u as "update to the latest version _possible_". Which is what it does mean, if you're fully on the testing or stable branch. As it is, you've manually specified you want to mix branches. How should portage resolve this? By telling you which additional packages to switch to testing? Or by ignoring the fact that you've asked for gtk+ to be on the testing branch, and settling for stable? Either way, it can't do what you've asked for, so why shouldn't that be a fatal error?
To me trying to run a keyworded gtk+ (or any package with so many inter-dependencies) on an otherwise stable system is really asking for trouble; wanting portage to make it easier for you to do this is even more so.
Last edited by kimmie on Tue Apr 24, 2012 7:43 am; edited 1 time in total |
|
| Back to top |
|
|
kimmie
Guru
Joined: 08 Sep 2004
Posts: 531
Location: Australia
|
| Posted: Tue Apr 24, 2012 7:42 am Post subject: |
|
|
| cach0rr0, I agree, I don't think portage is wrong. Like I said, I was distracted, and I was taking jaglover's comments more at face value, rather than in the context of this topic. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
