| View previous topic :: View next topic |
| Author |
Message |
Xanadu
Guru
Joined: 10 Oct 2002
Posts: 335
Location: Hour West of Philly (USA)
|
 Posted: Tue Mar 04, 2003 4:02 pm Post subject: Telling emerge *NOT* to update (downgrade) things. |
 |
|
Hey!
After having to do the ACCEPT_KEYWORDS="~x86" thing to get the new X, I've ran into a bit of a problem. If I leave that in, for obvious reasons, emerge wants to update 2/3 of my system. If I comment that out, it wants to downgrade everything I updated (namely the new X).  Now, first off, I'm on a modem.  Downloading 2/3 of my system again would be hell (to make an understatement). The box is fast, so compile time isn't an issue. So the point of all this is: I can no longer do a "emerge -u world" without emerge, one way or another, making my life (and potentially my box) a nightmare.
I've been doing a "emerge -pu world" and selectivly updating things (as best I can to stay current with upgrades and bug fixes, etc.), but honestly it's a real pain. I'm just wondering if there's a way around this.
Thanx all! |
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Tue Mar 04, 2003 5:23 pm Post subject: |
|
|
If your running a .47 version of portage, the U option should work. As in emerge -uUp world
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
axxackall
l33t
Joined: 06 Nov 2002
Posts: 651
Location: Toronto, Ontario, 3rd Rock From Sun
|
| Posted: Tue Mar 04, 2003 5:27 pm Post subject: Re: Telling emerge *NOT* to update (downgrade) things. |
|
|
| Xanadu wrote: | Hey!
After having to do the ACCEPT_KEYWORDS="~x86" thing to get the new X, I've ran into a bit of a problem. If I leave that in, for obvious reasons, emerge wants to update 2/3 of my system. If I comment that out, it wants to downgrade everything I updated (namely the new X). Now, first off, I'm on a modem. Downloading 2/3 of my system again would be hell (to make an understatement). The box is fast, so compile time isn't an issue. So the point of all this is: I can no longer do a "emerge -u world" without emerge, one way or another, making my life (and potentially my box) a nightmare.
I've been doing a "emerge -pu world" and selectivly updating things (as best I can to stay current with upgrades and bug fixes, etc.), but honestly it's a real pain. I'm just wondering if there's a way around this. |
First, you don't have to download everything again and again - once it's downloaded it sits there in /usr/portage/distfiles untill you delete it.
Second. you problem is one more vote for improving the portage, making two things:
(A) in order to give the user more fine-grained control, emerge should automatically pickup user-defined emerge-related variables per package. For example emerge would import (automatically if exist) the file /usr/local/portage/x11-base/xfree/make.conf where user can keep alternative (per only this package) ACCEPT_KEYWORDS, GENTOO_MIRRORS, CFLAGS and perhaps other stuff;
(B) in order to protect the user from being downgraded after next resync as well as in order to protect use to stick to outdated version in future, the format of /var/cache/edb/world should be consistent with ebuild-files and package.mask, namely it should accept and understand the form
| Code: | | >=x11-base/xfree-4.3.0 |
Having one or both such improvements will advance portage to be even more great package management system.
Anyone wanna implement it? |
|
| Back to top |
|
|
Xanadu
Guru
Joined: 10 Oct 2002
Posts: 335
Location: Hour West of Philly (USA)
|
| Posted: Tue Mar 04, 2003 5:46 pm Post subject: |
|
|
pjp wrote:
If your running a .47 version of portage, the U option should work. As in emerge -uUp world
~
OK, I'm trying that (on a test box of course...  ). I'll report back.
~~~~~~~~~~~
axxackall wrote (with some snip):
your problem is one more vote for improving the portage
~
I second this. There is (as far as I know) one major thing missing from portage that I was thinking about after my post. The way SuSE, MDK, and maybe even RH does upgrades, is broken into catagorys. Security, Upgrades, Un-Stable, etc. Portage, (again, AFAIK) doesn't have that granularity. *THAT* would be a REALLY nice thing.
Don't get me wrong (anyone who reads this), I REALLY like Gentoo (and have switched several people over to it because it's that damn good), but there's those little things like that that make it a *SLIGHT* headache. |
|
| Back to top |
|
|
axxackall
l33t
Joined: 06 Nov 2002
Posts: 651
Location: Toronto, Ontario, 3rd Rock From Sun
|
| Posted: Tue Mar 04, 2003 6:52 pm Post subject: |
|
|
| Xanadu wrote: | | I second this. There is (as far as I know) one major thing missing from portage that I was thinking about after my post. The way SuSE, MDK, and maybe even RH does upgrades, is broken into catagorys. Security, Upgrades, Un-Stable, etc. Portage, (again, AFAIK) doesn't have that granularity. *THAT* would be a REALLY nice thing. |
I agree. Today we have a global variable ACCEPT_KEYWORDS, which can have only three values applied to the given architecture: STABLE, UNTESTED, BROKEN. Perhaps, that besides granuling it by packages, it has to be granuled by more values. However, this kind of granularity is not clear: what other values do we need?
Remember, the prefix before architecture name answers for the question: "How is it stable?" Stable what? When we remember the question it is easy to answer. I would separate architecture from stability, instead of one ACCEPT_KEYWORDS variable, and then I would allow the following list of stability keywords: WITH_SECURITY_BUG, WITH_FUNCTIONALITY_BUG, OBSOLETE_BY_NEWER, STABLE, UNTESTED. No more TILDA, no more MINUS, use just a plain english instead
I see one serious issue with this proposals: people who can do it - don't like it, while people who like it - cannot do it. So when we'll have the guy who likes it and can do it - the problem of granularity of stability flags will be solved |
|
| Back to top |
|
|
cederberg
Guru
Joined: 23 Jan 2003
Posts: 349
Location: Stockholm / Sweden
|
| Posted: Tue Mar 04, 2003 10:32 pm Post subject: |
|
|
Well, isn't this what software development is all about? Never fully satisfying your users... ;-)
Anyway, thought you might be interested in a slightly related bug. It concerns the pain of writing "ACCEPT_KEYWORDS=~x86", which is one of the most frequent questions (and a source for error when people write - instead of ~).
Maybe you should add your suggestion in a comment there, just to complete the picture a bit. It would be sooo cute if we could one day write:
| Code: | | emerge -u --security world |
|
|
| Back to top |
|
|
Beekster
Apprentice
Joined: 26 Nov 2002
Posts: 268
Location: Sydney
|
| Posted: Wed Mar 05, 2003 1:59 am Post subject: |
|
|
Have come across another version issue:
| Code: | beekster01 root # emerge -pu world
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild U ] app-office/abiword-1.0.4_pre1-r1 [1.0.4]
beekster01 root # emerge -puU world
These are the packages that I would merge, in order:
Calculating world dependencies ...done!
[ebuild U ] app-office/abiword-1.0.4_pre1-r1 [1.0.4]
beekster01 root # ACCEPT_KEYWORDS='~x86' emerge -pu abiword
These are the packages that I would merge, in order:
Calculating dependencies ...done! |
I used ACCEPT_KEYWORDS to emerge abiword, and unless I'm mistaken, 1.0.4 is later than 1.0.4_pre1-r1... emerge disagrees, and yet wouldn't let me emerge 1.0.4 without using ACCEPT_KEYWORDS.  |
|
| Back to top |
|
|
Xanadu
Guru
Joined: 10 Oct 2002
Posts: 335
Location: Hour West of Philly (USA)
|
| Posted: Wed Mar 05, 2003 4:58 am Post subject: |
|
|
| pjp wrote: | | If your running a .47 version of portage, the U option should work. As in emerge -uUp world |
After thinking about it a bit (good thing I am trying it on a test machine first...), did you mean WITH ~x86 enabled, or without? On the test box I did it withOUT ~x86 enabled.
Just wondering. I guess I'll find out.  |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Wed Mar 05, 2003 5:46 am Post subject: |
|
|
Doesn't look like that feature ("big" U) is documented in the man page yet.
My understanding is that it prevents downgrades. Using -p (--pretend) would demostrate what it would do. So, if emerge -up world wants to downgrade something, -uUp should ignore downgrades.
To answer more directly, I don't think ~x86 matters. I have a package emerged with ~x86 that wants to downgrade with a normal -u. With -uU, it doesn't.
Hope that helps.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
axxackall
l33t
Joined: 06 Nov 2002
Posts: 651
Location: Toronto, Ontario, 3rd Rock From Sun
|
| Posted: Wed Mar 05, 2003 1:13 pm Post subject: |
|
|
| pjp wrote: | | To answer more directly, I don't think ~x86 matters. I have a package emerged with ~x86 that wants to downgrade with a normal -u. With -uU, it doesn't. |
One reason when "emrege -up world" wants to downgrade something is b/c before you upgraded something to TILDA level, taking a risky decision by yourself.
Another reason if one of upgraded packages requires to install another new one, and that new one wants explicitly one of already installed packages to be lower than specified version ("<" operator in DEPENDs or RDEPENDs).
From the prospective of breaking your system those are very-very different cases. In first case I agree to use "emerge -uUp world" as it reflects my own requirements - I am still willing to take a risk of testing one of masked packages. In second case, the forcing to ignore the dependency-based demand of downgrading can break someting. You still can decide to use or not to use "-U", but you don't have information for it as "-up" doesn't show the difference of those cases and therefore your decision of using "-U" will be blind unless you do your own investigation with "qpkg -q" (you may spend several hours in big and broad upgrades).
That's why the extending the world-file syntax by ">=" operator for injected records would help for first case, keeping the second case to work only depending on with "-U" or w/o "-U". |
|
| 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
