Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-16 Thread Adam Carter

  +1  It bit me, and just seems stupid.

 +1

 I like Neil's suggestion - eselect can put packages it knows about into a
 specially-named set.


I've logged the bug;
http://bugs.gentoo.org/show_bug.cgi?id=367611

Based on the quality of Neil's posts i'm sure you're right, but i'll leave
the devs to choose the solution. I've just requested the check in the bug
above, not make any suggestions on how to implement it.


Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-12 Thread Alan McKinnon
Apparently, though unproven, at 04:13 on Thursday 12 May 2011, Kevin O'Gorman 
did opine thusly:

 On Wed, May 11, 2011 at 4:53 PM, Adam Carter adamcart...@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...
  
  Sounds to me like that should be made into a feature request. What does
  the list think? If there's support I will log it.
 
 +1  It bit me, and just seems stupid.

+1

I like Neil's suggestion - eselect can put packages it knows about into a 
specially-named set.


-- 
alan dot mckinnon at gmail dot com



[gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-11 Thread Grant Edwards
On 2011-05-11, Grant Edwards grant.b.edwa...@gmail.com wrote:
 On 2011-05-10, Mick michaelkintz...@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.

That should have read weren't compatible with 2.7.

-- 
Grant Edwards   grant.b.edwardsYow! Can you MAIL a BEAN
  at   CAKE?
  gmail.com




Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-11 Thread Adam Carter

  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...


Sounds to me like that should be made into a feature request. What does the
list think? If there's support I will log it.


Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-11 Thread Kevin O'Gorman
On Wed, May 11, 2011 at 4:53 PM, Adam Carter adamcart...@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...


 Sounds to me like that should be made into a feature request. What does the
 list think? If there's support I will log it.


+1  It bit me, and just seems stupid.

-- 
Kevin O'Gorman, PhD


[gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-10 Thread Grant Edwards
On 2011-05-10, Alan McKinnon alan.mckin...@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.edwardsYow! I like the way ONLY
  at   their mouths move ...  They
  gmail.comlook like DYING OYSTERS




Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-10 Thread Alan McKinnon
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



[gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-10 Thread Grant Edwards
On 2011-05-10, Alan McKinnon alan.mckin...@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.edwardsYow! Hello...  IRON
  at   CURTAIN?  Send over a
  gmail.comSAUSAGE PIZZA!  World War
   III?  No thanks!




Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-10 Thread Neil Bothwick
On Tue, 10 May 2011 16:07:24 + (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.


signature.asc
Description: PGP signature


Re: [gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-10 Thread Mick
On Tuesday 10 May 2011 16:13:41 Grant Edwards wrote:
 On 2011-05-10, Alan McKinnon alan.mckin...@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


signature.asc
Description: This is a digitally signed message part.


[gentoo-user] Re: Prevent depclean from removing Python-2.6?

2011-05-10 Thread Grant Edwards
On 2011-05-10, Mick michaelkintz...@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