Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
accept_keywords: upgrade - downgrade problem
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
LoTeK
Apprentice
Apprentice


Joined: 26 Jul 2012
Posts: 270

PostPosted: Sun Mar 10, 2013 4:40 pm    Post subject: accept_keywords: upgrade - downgrade problem Reply with quote

hi,
A few days ago I added the qt-flag to my make.conf, because virtualbox has only a qt-GUI version and I thought I will try KDE again, so I recompiled the whole system (about 350 packages). Then I thought again and decided to not use virtualbox and to stay with dwm/euclid-wm, so I removed the qt-flag again... :)

this mess wasn't enough and a friend suggested to use ACCEPT_KEYWORDS="~amd64" and I gave it a try and recompiled everything, but now I can't upgrade everything and I get an error when trying to emerge glib-perl: depends on ExtUtils, so I tried to install ExtUtils-MakeMaker and it worked but after that the same error message appeared again.

Then I thought it's maybe better to stay without ACCEPT_KEYWORDS="~amd64", so now I'm trying to downgrade everything, but the procedure stops with:
stop downgrading sys-libs/glibc, because otherwise my system will be destroyed :)

So now I have two questions:
the first is how adventurously is it to use ACCEPT_KEYWORDS?

the second is:
how can I get out of this mess? should I try to force the downgrade of glibc?
_________________
"I want to see gamma rays! I want to hear X-rays! Do you see the absurdity of what I am? I can't even express these things properly because I have to conceptualize complex ideas in this stupid limiting spoken language!"
Back to top
View user's profile Send private message
Jaglover
Advocate
Advocate


Joined: 29 May 2005
Posts: 4563
Location: Saint Amant, Acadiana

PostPosted: Sun Mar 10, 2013 5:22 pm    Post subject: Reply with quote

Quote:
how can I get out of this mess?
By fixing one problem at a time.
Quote:
should I try to force the downgrade of glibc?

Sure, if you are determined to destroy your installation that's a good way. Everything that was built against new glibc will stop working. There is a thread about this, search the forum. Safest way back to stable is to wait until stable catches up.
_________________
Please learn how to denote units correctly!
Back to top
View user's profile Send private message
LoTeK
Apprentice
Apprentice


Joined: 26 Jul 2012
Posts: 270

PostPosted: Sun Mar 10, 2013 5:42 pm    Post subject: Reply with quote

I think you mean this krinn-thread: https://forums.gentoo.org/viewtopic-t-845000-start-0.html :)
Quote:
Safest way back to stable is to wait until stable catches up.

Ok, I hope stable will catch up fast, because I'm getting nervous if I can't run
Code:
emerge --update --deep --with-bdeps=y world

everyday :)
_________________
"I want to see gamma rays! I want to hear X-rays! Do you see the absurdity of what I am? I can't even express these things properly because I have to conceptualize complex ideas in this stupid limiting spoken language!"
Back to top
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 2161
Location: The Peanut Gallery

PostPosted: Thu Mar 14, 2013 12:02 am    Post subject: Reply with quote

LoTeK wrote:
Quote:
Safest way back to stable is to wait until stable catches up.

Ok, I hope stable will catch up fast, because I'm getting nervous if I can't run
Code:
emerge --update --deep --with-bdeps=y world

everyday :)

Heh; I'd just put =sys-libs/glibc-2.16.x where x is the currently-installed version, in /etc/portage/package.keywords so that portage doesn't try to downgrade it.

You can put individual packages (ie just the names) in there too, which is the usual way to unmask packages you're interested in; or for instance <cat-foo/pkg-bar-2.5 if pkg-bar-2.4 is mostly stable, and you want to run unstable 2.4 but not automatically upgrade it to a later 2.5 series when that hits. You can also do that with slots: cat-foo/pkg-bar:2.4. See man portage for more info on DEPEND atoms and the various files you can tweak.

I know how to do all this, but I haven't done it manually for years so sorry if I've got a typo in there somewhere. I let update handle all this for me, either when a dependency needs to be unmasked: it asks if I want to unmask what portage is suggesting, package at a time, does the edit and shows me a coloured diff of relevant files, or shows me the license and asks if I want to accept. Or when I want to install a package, eg: update -ia pkg-bar will ask me if I want to unmask the package if it's unstable (since we're installing it to world, it'll unmask the Package by default), or for an installed package, eg: update pkg-bar-2.4.8 will unmask the Version by default, or I can tell it to unmask the Slot (if it's multi-slotted) or the Package with S or P. Again it shows me a diff of all unmasks at once when I confirm the changes (press space, enter or Y; or N to cancel.)

Along with a similar process for USE flags (reviewed and set via the dialog front-end) I haven't had to go near the /etc/portage/package.* files for ages, though I check them once a year or so for cruft. Similarly for make.conf, though I added FEATURES=multilib-strict recently after reading about it on the amd64 AT pages.

Currently FEATURES="buildpkg splitdebug compressdebug news split-log split-elog
userfetch userpriv usersandbox usersync multilib-strict"
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
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