| View previous topic :: View next topic |
| Author |
Message |
LoTeK
Apprentice
Joined: 26 Jul 2012
Posts: 270
|
 Posted: Sun Mar 10, 2013 4:40 pm Post subject: accept_keywords: upgrade - downgrade problem |
 |
|
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 |
|
 |
Jaglover
Watchman
Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana
|
| Posted: Sun Mar 10, 2013 5:22 pm Post subject: |
|
|
| 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.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly! |
|
| Back to top |
|
|
LoTeK
Apprentice
Joined: 26 Jul 2012
Posts: 270
|
| Posted: Sun Mar 10, 2013 5:42 pm Post subject: |
|
|
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 |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Mar 14, 2013 12:02 am Post subject: |
|
|
| 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 |
|
|
|
|
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
