Prevent depclean from removing Python-2.6?
Apparently, though unproven, at 16:40 on Tuesday 10 May 2011, Grant Edwards
did opine thusly: > I ran emerge --depclean the other day on one of my machines and it > removed Python 2.6. I was using Python 2.6 as my "default" python, > and depclean's removal of it broke a _lot_ of stuff. About a half > day's worth of hassle later I had Python 2.6 re-installed and my > system was again usable. > > In order to avoid the same circus on my other machines, how do I > prevent emerge --depclean from removing Python 2.6? Put that slot in world: =dev-lang/python:2.6 I suppose there are better and more automagically elegant ways of doing it, but this works. I think the issue happens because portage does not take eselect choices into account when building it's dep graph, it only uses the DEPENDS in ebuilds. You likely have nothing left that explicitly uses 2.6 and all the ebuilds depend only on python 2 point something When you finally choose to remove python-2.6, you simply have to emerge -C it and not rely on --depclean -- alan dot mckinnon at gmail dot com |
Prevent depclean from removing Python-2.6?
Apparently, though unproven, at 16:40 on Tuesday 10 May 2011, Grant Edwards
did opine thusly: > I ran emerge --depclean the other day on one of my machines and it > removed Python 2.6. I was using Python 2.6 as my "default" python, > and depclean's removal of it broke a _lot_ of stuff. About a half > day's worth of hassle later I had Python 2.6 re-installed and my > system was again usable. > > In order to avoid the same circus on my other machines, how do I > prevent emerge --depclean from removing Python 2.6? Put that slot in world: =dev-lang/python:2.6 I suppose there are better and more automagically elegant ways of doing it, but this works. I think the issue happens because portage does not take eselect choices into account when building it's dep graph, it only uses the DEPENDS in ebuilds. You likely have nothing left that explicitly uses 2.6 and all the ebuilds depend only on python 2 point something When you finally choose to remove python-2.6, you simply have to emerge -C it and not rely on --depclean -- alan dot mckinnon at gmail dot com |
Prevent depclean from removing Python-2.6?
On 2011-05-10, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Apparently, though unproven, at 16:40 on Tuesday 10 May 2011, Grant Edwards > did opine thusly: > >> I ran emerge --depclean the other day on one of my machines and it >> removed Python 2.6. I was using Python 2.6 as my "default" python, >> and depclean's removal of it broke a _lot_ of stuff. About a half >> day's worth of hassle later I had Python 2.6 re-installed and my >> system was again usable. >> >> In order to avoid the same circus on my other machines, how do I >> prevent emerge --depclean from removing Python 2.6? > > Put that slot in world: > >=dev-lang/python:2.6 > > I suppose there are better and more automagically elegant ways of doing it, > but this works. Thanks! (you need to leave out the '='). > I think the issue happens because portage does not take eselect > choices into account when building it's dep graph, it only uses the > DEPENDS in ebuilds. Apparently so. It seems like it ought to pay attention to eselect. If I've explicitly configured my system to use 2.6 instead of 2.7, removing 2.6 doesn't seem like a good thing... > You likely have nothing left that explicitly uses 2.6 and all the > ebuilds depend only on python 2 point something > > When you finally choose to remove python-2.6, you simply have to > emerge -C it and not rely on --depclean Yup. -- Grant Edwards grant.b.edwards Yow! I like the way ONLY at their mouths move ... They gmail.com look like DYING OYSTERS |
Prevent depclean from removing Python-2.6?
On 2011-05-10, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Apparently, though unproven, at 16:40 on Tuesday 10 May 2011, Grant Edwards > did opine thusly: > >> I ran emerge --depclean the other day on one of my machines and it >> removed Python 2.6. I was using Python 2.6 as my "default" python, >> and depclean's removal of it broke a _lot_ of stuff. About a half >> day's worth of hassle later I had Python 2.6 re-installed and my >> system was again usable. >> >> In order to avoid the same circus on my other machines, how do I >> prevent emerge --depclean from removing Python 2.6? > > Put that slot in world: > >=dev-lang/python:2.6 > > I suppose there are better and more automagically elegant ways of doing it, > but this works. Thanks! (you need to leave out the '='). > I think the issue happens because portage does not take eselect > choices into account when building it's dep graph, it only uses the > DEPENDS in ebuilds. Apparently so. It seems like it ought to pay attention to eselect. If I've explicitly configured my system to use 2.6 instead of 2.7, removing 2.6 doesn't seem like a good thing... > You likely have nothing left that explicitly uses 2.6 and all the > ebuilds depend only on python 2 point something > > When you finally choose to remove python-2.6, you simply have to > emerge -C it and not rely on --depclean Yup. -- Grant Edwards grant.b.edwards Yow! I like the way ONLY at their mouths move ... They gmail.com look like DYING OYSTERS |
Prevent depclean from removing Python-2.6?
Apparently, though unproven, at 17:13 on Tuesday 10 May 2011, Grant Edwards
did opine thusly: > > I think the issue happens because portage does not take eselect > > choices into account when building it's dep graph, it only uses the > > DEPENDS in ebuilds. > > Apparently so. It seems like it ought to pay attention to eselect. > If I've explicitly configured my system to use 2.6 instead of 2.7, > removing 2.6 doesn't seem like a good thing... There's one more wrinkle though: portage, ebuilds and EAPI are all portable to other systems (funtoo etc) whereas eselect is very gentoo-specific. So putting gentooism support into portage would be counter-productive. A real solution would require some kind of generic statement in ebuilds that would allow for optional dependencies. I haven't thought this completely through, but maybe something like the following: - A new keyword in ebuilds to indicate packages with soft deps - A new file format that lists these deps currently in use - Tools like eselect could update this file as they adjust user preferences This way, portage would have additional info available about unusual packages still in use when --depclean runs. -- alan dot mckinnon at gmail dot com |
Prevent depclean from removing Python-2.6?
Apparently, though unproven, at 17:13 on Tuesday 10 May 2011, Grant Edwards
did opine thusly: > > I think the issue happens because portage does not take eselect > > choices into account when building it's dep graph, it only uses the > > DEPENDS in ebuilds. > > Apparently so. It seems like it ought to pay attention to eselect. > If I've explicitly configured my system to use 2.6 instead of 2.7, > removing 2.6 doesn't seem like a good thing... There's one more wrinkle though: portage, ebuilds and EAPI are all portable to other systems (funtoo etc) whereas eselect is very gentoo-specific. So putting gentooism support into portage would be counter-productive. A real solution would require some kind of generic statement in ebuilds that would allow for optional dependencies. I haven't thought this completely through, but maybe something like the following: - A new keyword in ebuilds to indicate packages with soft deps - A new file format that lists these deps currently in use - Tools like eselect could update this file as they adjust user preferences This way, portage would have additional info available about unusual packages still in use when --depclean runs. -- alan dot mckinnon at gmail dot com |
Prevent depclean from removing Python-2.6?
On 2011-05-10, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> Apparently, though unproven, at 17:13 on Tuesday 10 May 2011, Grant Edwards > did opine thusly: > >> > I think the issue happens because portage does not take eselect >> > choices into account when building it's dep graph, it only uses the >> > DEPENDS in ebuilds. >> >> Apparently so. It seems like it ought to pay attention to eselect. >> If I've explicitly configured my system to use 2.6 instead of 2.7, >> removing 2.6 doesn't seem like a good thing... > > There's one more wrinkle though: > > portage, ebuilds and EAPI are all portable to other systems (funtoo etc) > whereas eselect is very gentoo-specific. Ah. I didn't realise that eselect was gentoo-specific. > So putting gentooism support into portage would be > counter-productive. > > A real solution would require some kind of generic statement in > ebuilds that would allow for optional dependencies. I haven't thought > this completely through, but maybe something like the following: > > - A new keyword in ebuilds to indicate packages with soft deps > - A new file format that lists these deps currently in use > - Tools like eselect could update this file as they adjust user preferences > > This way, portage would have additional info available about unusual > packages still in use when --depclean runs. Perhaps having eselect add currently selected slots to the world file would be sufficient? -- Grant Edwards grant.b.edwards Yow! Hello... IRON at CURTAIN? Send over a gmail.com SAUSAGE PIZZA! World War III? No thanks! |
Prevent depclean from removing Python-2.6?
On Tue, 10 May 2011 16:07:24 +0000 (UTC), Grant Edwards wrote:
> Perhaps having eselect add currently selected slots to the world file > would be sufficient? Not the world file, that would be horrible, but they could be added to a spacial set. -- Neil Bothwick Three kinds of people: Those who can count, and those who can't. |
Prevent depclean from removing Python-2.6?
On Tuesday 10 May 2011 16:13:41 Grant Edwards wrote:
> On 2011-05-10, Alan McKinnon <alan.mckinnon@gmail.com> wrote: > > Apparently, though unproven, at 16:40 on Tuesday 10 May 2011, Grant > > Edwards > > > > did opine thusly: > >> I ran emerge --depclean the other day on one of my machines and it > >> removed Python 2.6. I was using Python 2.6 as my "default" python, > >> and depclean's removal of it broke a _lot_ of stuff. About a half > >> day's worth of hassle later I had Python 2.6 re-installed and my > >> system was again usable. > >> > >> In order to avoid the same circus on my other machines, how do I > >> prevent emerge --depclean from removing Python 2.6? > > > > Put that slot in world: > >=dev-lang/python:2.6 > > > > I suppose there are better and more automagically elegant ways of doing > > it, but this works. > > Thanks! > > (you need to leave out the '='). > > > I think the issue happens because portage does not take eselect > > choices into account when building it's dep graph, it only uses the > > DEPENDS in ebuilds. > > Apparently so. It seems like it ought to pay attention to eselect. > If I've explicitly configured my system to use 2.6 instead of 2.7, > removing 2.6 doesn't seem like a good thing... I am not sure I understand: If you eselect python 2.7 and run python-updater (and revdep-rebuild just in case) I would think that you *should* have a working system. Unless some particular package is hardcoded to use 2.6 things should not really break. Am I wrong here? -- Regards, Mick |
Prevent depclean from removing Python-2.6?
On 2011-05-10, Mick <michaelkintzios@gmail.com> wrote:
>> Apparently so. It seems like it ought to pay attention to eselect. >> If I've explicitly configured my system to use 2.6 instead of 2.7, >> removing 2.6 doesn't seem like a good thing... > > I am not sure I understand: > > If you eselect python 2.7 and run python-updater (and revdep-rebuild > just in case) I would think that you *should* have a working system. I have a number of python libraries installed that don't have ebuilds. At one point some of them weren't compatible with 2.6. I don't know if that's still the case, but I don't have time right now to go through that exercise on three machines. So I'm sticking with python 2.6 for the time being. > Unless some particular package is hardcoded to use 2.6 things should > not really break. > > Am I wrong here? It depends on what python apps/libraries you depend on. I'm sure everything that was installed via emerge would be OK. -- Grant |
| All times are GMT. The time now is 11:25 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.