[gentoo-dev] emerge -C eselect-python disaster

[gentoo-dev] emerge -C eselect-python disaster

[Benny Pedersen]

should not be marked as system ?

it removes python-wrapper and this remove python link from  
/usr/bin/python linked to /usr/bin/python-wrapper so all portage does  
not work after this, but i solved it with a quickpkg from another host

my dump question why is it not listed as a system pkg when it really  
seems so important ?

-- 
xpoint

Re: [gentoo-dev] emerge -C eselect-python disaster

[Ulrich Mueller]

>>>>> On Sun, 24 Jan 2010, Benny Pedersen wrote:

> it removes python-wrapper and this remove python link from
> /usr/bin/python linked to /usr/bin/python-wrapper so all portage
> does not work after this,

It's a run-time dependency of python, so what did you expect?

> my dump question why is it not listed as a system pkg when it really
> seems so important ?

Python itself is not in the system set, so why should the eselect
module be?

Ulrich

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On 01/24/2010 07:12 AM, Benny Pedersen wrote:
> 
> should not be marked as system ?
> 
> it removes python-wrapper and this remove python link from
> /usr/bin/python linked to /usr/bin/python-wrapper so all portage does
> not work after this, but i solved it with a quickpkg from another host
> 
> my dump question why is it not listed as a system pkg when it really
> seems so important ?
> 

Removing packages with emerge -C is always potentially dangerous. The
recommended tool these days is emerge --depclean. emerge -C really only
comes to use with blockers and then maintainers should design the
upgrade paths so that you don't need to remove anything that breaks things.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On 01/24/2010 07:12 AM, Benny Pedersen wrote:
> 
> should not be marked as system ?
> 
> it removes python-wrapper and this remove python link from
> /usr/bin/python linked to /usr/bin/python-wrapper so all portage does
> not work after this, but i solved it with a quickpkg from another host
> 
> my dump question why is it not listed as a system pkg when it really
> seems so important ?
> 

The meaning of the system set is to have only the packages directly
required to have a minimal functioning system. Having python by itself
is not a requirement for that but having package management is. As a
consequence python gets pulled in by portage. We could have a separate
list for packages for which the PM should tell the user that he's an
idiot of course but the best thing is to educate users that emerge -C is
dangerous.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Ben de Groot]

2010/1/24 Petteri Räty <betelgeuse@gentoo.org>:
> The meaning of the system set is to have only the packages directly
> required to have a minimal functioning system. Having python by itself
> is not a requirement for that but having package management is.

You can't have functioning package management without the hard
dependencies it requires. So both portage and python should be in the
system set.

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On 01/24/2010 03:02 PM, Ben de Groot wrote:
> 2010/1/24 Petteri Räty <betelgeuse@gentoo.org>:
>> The meaning of the system set is to have only the packages directly
>> required to have a minimal functioning system. Having python by itself
>> is not a requirement for that but having package management is.
> 
> You can't have functioning package management without the hard
> dependencies it requires. So both portage and python should be in the
> system set.
> 
> Cheers,

Why should we keep redundant information in the list?

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Ben de Groot]

2010/1/24 Petteri Räty <betelgeuse@gentoo.org>:
> On 01/24/2010 03:02 PM, Ben de Groot wrote:
>> You can't have functioning package management without the hard
>> dependencies it requires. So both portage and python should be in the
>> system set.
>
> Why should we keep redundant information in the list?

How is that redundant?

Cheers,
-- 
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
______________________________________________________

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On 01/24/2010 08:20 PM, Ben de Groot wrote:
> 2010/1/24 Petteri Räty <betelgeuse@gentoo.org>:
>> On 01/24/2010 03:02 PM, Ben de Groot wrote:
>>> You can't have functioning package management without the hard
>>> dependencies it requires. So both portage and python should be in the
>>> system set.
>>
>> Why should we keep redundant information in the list?
> 
> How is that redundant?
> 
> Cheers,

The problem the original poster wanted to solve is having a warning when
trying to unmerge something in "system". The best way here is to file a
Portage enhancement request and not pollute the profile system set
marking. The purpose of the packages file is to describe what needs to
be installed for a minimal system to work so it doesn't make sense to
pollute it with implementation details.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Petteri Räty wrote:
> On 01/24/2010 08:20 PM, Ben de Groot wrote:
>   
>> 2010/1/24 Petteri Räty <betelgeuse@gentoo.org>:
>>     
>>> On 01/24/2010 03:02 PM, Ben de Groot wrote:
>>>       
>>>> You can't have functioning package management without the hard
>>>> dependencies it requires. So both portage and python should be in the
>>>> system set.
>>>>         
>>> Why should we keep redundant information in the list?
>>>       
>> How is that redundant?
>>
>> Cheers,
>>     
>
> The problem the original poster wanted to solve is having a warning when
> trying to unmerge something in "system". The best way here is to file a
> Portage enhancement request and not pollute the profile system set
> marking. The purpose of the packages file is to describe what needs to
> be installed for a minimal system to work so it doesn't make sense to
> pollute it with implementation details.
>
> Regards,
> Petteri
>
>   

Since unmerging python results in a broken system, I'm not sure how this 
"pollutes" anything.  The system set is to maintain a working and 
bootable system that can install packages and portage requires python to 
work.  What good is a Gentoo system without a working package manager?

Is there something that I am missing here?  For me, system should 
include the things needed for booting and for the package manager to 
work.  If it can't contain python then portage has a problem.  As I 
pointed out in another reply, portage won't let you unmerge itself but 
it will let you unmerge a package that will render portage useless.  If 
I can unmerge python then portage should just go ahead and let me 
unmerge portage itself too.  At least it is easier to repair removing 
portage. 

Dale

:-)  :-)

Re: [gentoo-dev] emerge -C eselect-python disaster

[Jacob Godserv]

On Sun, Jan 24, 2010 at 19:02, Dale <rdalek1967@gmail.com> wrote:
> Since unmerging python results in a broken system, I'm not sure how this
> "pollutes" anything.  The system set is to maintain a working and bootable
> system that can install packages and portage requires python to work.  What
> good is a Gentoo system without a working package manager?

There are two issues here:

* Avoiding hacks for deciding which packages are needed for system
* Helping users avoid the dangerous mistake of crippling the package manager.

Here's how I see this break down. To avoid crippling the package
manager, the user must be warned of an action that will cripple the
package manager. If removing python cripples the package manager, then
warn the user. It's quite simple. Adding python to the system set is
messy, as pointed out, but somehow there must be a way to determine
that python is needed by the package manager.

The last remaining option (without adding any new features) is to
track on which packages are required by the system set and warning
about removing any packages required by any package in the system set.
This seems like a good solution.


I could also argue that using "emerge -C" period is dangerous, as some
here have mentioned. As far as I can tell, the best way to remove a
package is to edit the package out of /var/lib/portage/world file and
then letting portage safely remove packages via "--depclean". (This is
outside the current topic, of course, so if anyone wants to seriously
propose this it should be re-posted under a new subject heading.)

-- 
    Jacob

    "For then there will be great distress, unequaled
    from the beginning of the world until now — and never
    to be equaled again. If those days had not been cut
    short, no one would survive, but for the sake of the
    elect those days will be shortened."

    Are you ready?

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Jacob Godserv wrote:
> On Sun, Jan 24, 2010 at 19:02, Dale <rdalek1967@gmail.com> wrote:
>   
>> Since unmerging python results in a broken system, I'm not sure how this
>> "pollutes" anything.  The system set is to maintain a working and bootable
>> system that can install packages and portage requires python to work.  What
>> good is a Gentoo system without a working package manager?
>>     
>
> There are two issues here:
>
> * Avoiding hacks for deciding which packages are needed for system
> * Helping users avoid the dangerous mistake of crippling the package manager.
>
> Here's how I see this break down. To avoid crippling the package
> manager, the user must be warned of an action that will cripple the
> package manager. If removing python cripples the package manager, then
> warn the user. It's quite simple. Adding python to the system set is
> messy, as pointed out, but somehow there must be a way to determine
> that python is needed by the package manager.
>
> The last remaining option (without adding any new features) is to
> track on which packages are required by the system set and warning
> about removing any packages required by any package in the system set.
> This seems like a good solution.
>
>
> I could also argue that using "emerge -C" period is dangerous, as some
> here have mentioned. As far as I can tell, the best way to remove a
> package is to edit the package out of /var/lib/portage/world file and
> then letting portage safely remove packages via "--depclean". (This is
> outside the current topic, of course, so if anyone wants to seriously
> propose this it should be re-posted under a new subject heading.)
>
>   

Well put.  I would agree that a simple warning should be given before 
removing a system package or a package that system must have, especially 
portage. 

Maybe what portage needs is a reverse -n feature.  Instead of adding 
something to the world file, it removes a unwanted package from the 
world file and then the user could use --depclean to remove that package 
and its no longer needed friends.  I assume this is doable.

Dale

:-)  :-)

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On 01/25/2010 04:28 AM, Dale wrote:
> 
> Well put.  I would agree that a simple warning should be given before
> removing a system package or a package that system must have, especially
> portage.
> Maybe what portage needs is a reverse -n feature.  Instead of adding
> something to the world file, it removes a unwanted package from the
> world file and then the user could use --depclean to remove that package
> and its no longer needed friends.  I assume this is doable.
> 

You can already use --depclean for this.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Petteri Räty wrote:
> On 01/25/2010 04:28 AM, Dale wrote:
>   
>> Well put.  I would agree that a simple warning should be given before
>> removing a system package or a package that system must have, especially
>> portage.
>> Maybe what portage needs is a reverse -n feature.  Instead of adding
>> something to the world file, it removes a unwanted package from the
>> world file and then the user could use --depclean to remove that package
>> and its no longer needed friends.  I assume this is doable.
>>
>>     
>
> You can already use --depclean for this.
>
> Regards,
> Petteri
>
>   

So there is already a option that is the reverse of -n ?

Dale

:-)  :-) 

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

On 25.1.2010 13.02, Dale wrote:
> Petteri Räty wrote:
>> On 01/25/2010 04:28 AM, Dale wrote:
>>> Well put. I would agree that a simple warning should be given before
>>> removing a system package or a package that system must have, especially
>>> portage.
>>> Maybe what portage needs is a reverse -n feature. Instead of adding
>>> something to the world file, it removes a unwanted package from the
>>> world file and then the user could use --depclean to remove that package
>>> and its no longer needed friends. I assume this is doable.
>>>
>>
>> You can already use --depclean for this.
>>
>> Regards,
>> Petteri
>>
>
> So there is already a option that is the reverse of -n ?
>
> Dale
>
> :-) :-)


You would first have to define the reverse to avoid misunderstanding.

        --noreplace (-n)
               Skips  the packages specified on the command-line that 
have already been installed.

Reverse: Install packages that are not already installed

- This is what Portage does by default

Reverse: Skips packages that are not installed

- Makes no sense with installation actions. Is this what you mean?

pena betelgeuse # emerge --depclean foobar
 >>> No packages selected for removal by depclean

Regards,
Petteri

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

On 25.1.2010 13.30, Petteri Räty wrote:
>>
>> So there is already a option that is the reverse of -n ?
>>
>> Dale
>>
>> :-) :-)
>
>
> You would first have to define the reverse to avoid misunderstanding.
>
> --noreplace (-n)
> Skips the packages specified on the command-line that have already been
> installed.
>
> Reverse: Install packages that are not already installed
>
> - This is what Portage does by default
>
> Reverse: Skips packages that are not installed
>
> - Makes no sense with installation actions. Is this what you mean?
>
> pena betelgeuse # emerge --depclean foobar
>  >>> No packages selected for removal by depclean
>
> Regards,
> Petteri
>

I should also add that this is not a user support mailing list as 
there's gentoo-user for that purpose. I think the original purpose of 
the thread was already fulfilled.

Regards,
Petteri

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Petteri Räty wrote:
> On 25.1.2010 13.30, Petteri Räty wrote:
>>>
>>> So there is already a option that is the reverse of -n ?
>>>
>>> Dale
>>>
>>> :-) :-)
>>
>>
>> You would first have to define the reverse to avoid misunderstanding.
>>
>> --noreplace (-n)
>> Skips the packages specified on the command-line that have already been
>> installed.
>>
>> Reverse: Install packages that are not already installed
>>
>> - This is what Portage does by default
>>
>> Reverse: Skips packages that are not installed
>>
>> - Makes no sense with installation actions. Is this what you mean?
>>
>> pena betelgeuse # emerge --depclean foobar
>>  >>> No packages selected for removal by depclean
>>
>> Regards,
>> Petteri
>>
>
> I should also add that this is not a user support mailing list as 
> there's gentoo-user for that purpose. I think the original purpose of 
> the thread was already fulfilled.
>
> Regards,
> Petteri
>
>

Definition of reverse -n option.  emerge --remove-from-world pidgin  
That would remove the entry pidgin from the world file.  Then a user 
could use --depclean to remove pidgin and other dependencies that are no 
longer needed.  There would be no need to use -C in that case.

I am subscribed to -user as well.  I been using Gentoo since the 1.4 
days.  This is about improving portage which is a good thing to talk 
about here.  The devs do it, not the user.  ;-)  Also, I already know 
how to use portage pretty good.  I'm not asking for support just trying 
to improve things.

Dale

:-)  :-)

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

On 25.1.2010 18.06, Dale wrote:
>
> I am subscribed to -user as well. I been using Gentoo since the 1.4
> days. This is about improving portage which is a good thing to talk
> about here. The devs do it, not the user. ;-) Also, I already know how
> to use portage pretty good. I'm not asking for support just trying to
> improve things.
>

I categorize it as user support when trying to explain things that you 
can find out in the Portage man pages. I know we don't do a good job at 
communicating new things to users but improving that belongs to an 
another thread.

Regards,
Petteri

[gentoo-dev] Re: emerge -C eselect-python disaster

[Duncan]

Dale posted on Mon, 25 Jan 2010 10:06:06 -0600 as excerpted:

> I am subscribed to -user as well.  I been using Gentoo since the 1.4
> days.  This is about improving portage which is a good thing to talk
> about here.  The devs do it, not the user.  ;-)  Also, I already know
> how to use portage pretty good.  I'm not asking for support just trying
> to improve things.

Do note that there's a portage-specific list as well.  IDR what the name 
is but on gmane (where I follow it) it's the 
gmane.linux.gentoo.portage.devel newsgroup.  It's not a user list either, 
but they're reasonably friendly and it wouldn't be bothering the non-
portage devs that way.

As for this, I say let it be (except for possibly making -C output a 
bigger warning in general).  The documentation is pretty clear, and Gentoo 
never has been about hand-holding.  If a user can't read the documentation 
and thus asks to screw themselves, Gentoo provides the tools to do it -- 
and they're POWER tools, too! =:^)  I don't see that changing and don't 
believe it should.  There's other distributions out there for users who 
want or need a namby-pamby baby-sat hand-held version. Gentoo is not and 
never has been the right choice for them, and I don't believe we should be 
trying to make it so.  (That said, a warning on -C similar to that on -c, 
might be wise, but that's an implementation detail the discussion of which 
doesn't belong here.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] emerge -C eselect-python disaster

[Jacob Godserv]

On Mon, Jan 25, 2010 at 06:32, Petteri Räty <betelgeuse@gentoo.org> wrote:
> I should also add that this is not a user support mailing list as there's
> gentoo-user for that purpose. I think the original purpose of the thread was
> already fulfilled.

So then how was the original problem resolved? Sorry, I missed that
(and can't seem to find a resolution in this thread).

-- 
    Jacob

    "For then there will be great distress, unequaled
    from the beginning of the world until now — and never
    to be equaled again. If those days had not been cut
    short, no one would survive, but for the sake of the
    elect those days will be shortened."

    Are you ready?

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

On 25.1.2010 18.20, Jacob Godserv wrote:
> On Mon, Jan 25, 2010 at 06:32, Petteri Räty<betelgeuse@gentoo.org>  wrote:
>> I should also add that this is not a user support mailing list as there's
>> gentoo-user for that purpose. I think the original purpose of the thread was
>> already fulfilled.
>
> So then how was the original problem resolved? Sorry, I missed that
> (and can't seem to find a resolution in this thread).
>

There's already an open bug in Portage and the system set won't be 
changed for this.

Regards,
Petteri

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Petteri Räty wrote:
> On 25.1.2010 18.20, Jacob Godserv wrote:
>> On Mon, Jan 25, 2010 at 06:32, Petteri Räty<betelgeuse@gentoo.org>  
>> wrote:
>>> I should also add that this is not a user support mailing list as 
>>> there's
>>> gentoo-user for that purpose. I think the original purpose of the 
>>> thread was
>>> already fulfilled.
>>
>> So then how was the original problem resolved? Sorry, I missed that
>> (and can't seem to find a resolution in this thread).
>>
>
> There's already an open bug in Portage and the system set won't be 
> changed for this.
>
> Regards,
> Petteri
>
>

So it's not resolved, there just won't be any changes?

Dale

:-)  :-)

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On 01/25/2010 07:07 PM, Dale wrote:
> Petteri Räty wrote:
>> On 25.1.2010 18.20, Jacob Godserv wrote:
>>> On Mon, Jan 25, 2010 at 06:32, Petteri Räty<betelgeuse@gentoo.org> 
>>> wrote:
>>>> I should also add that this is not a user support mailing list as
>>>> there's
>>>> gentoo-user for that purpose. I think the original purpose of the
>>>> thread was
>>>> already fulfilled.
>>>
>>> So then how was the original problem resolved? Sorry, I missed that
>>> (and can't seem to find a resolution in this thread).
>>>
>>
>> There's already an open bug in Portage and the system set won't be
>> changed for this.
>>
>> Regards,
>> Petteri
>>
>>
> 
> So it's not resolved, there just won't be any changes?
> 
> Dale
> 

There's nothing more to discuss on this mailing list so from the mailing
list stand point the the thread is done. Any implementation details etc
belong to bugzilla.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Patrick Nagel]

[-- Attachment #1: Type: Text/Plain, Size: 578 bytes --]

Hi,

(although this is no user support list...)

On 2010-01-25 11:02 UTC Dale wrote:
> So there is already a option that is the reverse of -n ?

See `man emerge`:

--depclean (-c)
[...]
Depclean serves as a dependency aware version of --unmerge. When given 
one or more atoms, it will unmerge matched packages that have no reverse 
dependencies. Use --depclean together with --verbose to show reverse 
dependencies.

Patrick.

-- 
Key ID: 0x86E346D4            http://patrick-nagel.net/key.asc
Fingerprint: 7745 E1BE FA8B FBAD 76AB 2BFC C981 E686 86E3 46D4

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Richard Freeman]

On 01/24/2010 07:02 PM, Dale wrote:
> Is there something that I am missing here? For me, system should
> include the things needed for booting and for the package manager to
>  work.

It should include the programs directly involved in booting, and the
package manager.  I'm not sure that it should contain their dependencies
- since that information can be derived from the packages themselves.

> As I pointed out in another reply, portage won't let you unmerge
> itself but it will let you unmerge a package that will render portage
> useless.

Well, it shouldn't allow you to unmerge anything that will render
ANYTHING useless without some explicit instruction to do so.

The documentation does warn of this behavior:

--unmerge (-C)
WARNING: This action can remove important packages! Removes  all 
matching packages.  This does no checking of dependencies, so it
may remove packages necessary for the proper operation  of your
system.  Its arguments can be atoms or ebuilds. For a dependency
aware version of --unmerge, use --depclean or --prune.

If you use --depclean to remove your package then you're safe.

Note - the command line option names are not well-chosen here.  -C 
should really be --unmerge-without-checking-dependencies-unsafe or some 
other obnoxious option, and --depclean should be the easy to type parameter.

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Richard Freeman wrote:
> On 01/24/2010 07:02 PM, Dale wrote:
>> Is there something that I am missing here? For me, system should
>> include the things needed for booting and for the package manager to
>>  work.
>
> It should include the programs directly involved in booting, and the
> package manager.  I'm not sure that it should contain their dependencies
> - since that information can be derived from the packages themselves.

I see your point but if removing python renders portage useless, then 
portage is not any good either.  So, if portage will not warn against 
removing python, it may as well not warn about removing portage either.  
The system needs both to work.

>
>> As I pointed out in another reply, portage won't let you unmerge
>> itself but it will let you unmerge a package that will render portage
>> useless.
>
> Well, it shouldn't allow you to unmerge anything that will render
> ANYTHING useless without some explicit instruction to do so.
>
> The documentation does warn of this behavior:
>
> --unmerge (-C)
> WARNING: This action can remove important packages! Removes  all 
> matching packages.  This does no checking of dependencies, so it
> may remove packages necessary for the proper operation  of your
> system.  Its arguments can be atoms or ebuilds. For a dependency
> aware version of --unmerge, use --depclean or --prune.
>
> If you use --depclean to remove your package then you're safe.
>
> Note - the command line option names are not well-chosen here.  -C 
> should really be --unmerge-without-checking-dependencies-unsafe or 
> some other obnoxious option, and --depclean should be the easy to type 
> parameter.
>
>

I agree that since --depclean has improved, a LOT, that it is the safest 
way to remove a package.  Maybe that reverse -n feature may be 
considered.  Reserve the -C for someone that knows what not to remove.

Dale

:-)  :-) 

Re: [gentoo-dev] emerge -C eselect-python disaster

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On 01/25/2010 02:02 AM, Dale wrote:

> Is there something that I am missing here?  For me, system should
> include the things needed for booting and for the package manager to
> work.  If it can't contain python then portage has a problem.  As I
> pointed out in another reply, portage won't let you unmerge itself but
> it will let you unmerge a package that will render portage useless.  If
> I can unmerge python then portage should just go ahead and let me
> unmerge portage itself too.  At least it is easier to repair removing
> portage.
> Dale
> 

Again let's try again so maybe you understand the issues here. You can
see the contents of the system set like this:

emerge --nodeps -epv @system (on Portage 2.2)

It doesn't have eselect-python:

pena portage-trunk # emerge --nodeps -epv @system | grep eselect-python
pena portage-trunk #

You must differentiate between the @system set and what you think of as
"system packages". The set should for maintenance reasons reflect it's
true purpose. Again you can file a bug for Portage to warn about
removing it's deps and Portage maintainers can see if it's feasibly doable.

Another thing we should consider is writing a news item educating users
how to use Portage properly these days. At least ACCEPT_LICENSE and
--depclean need attention.

Regards,
Petteri



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Richard Freeman]

On 01/24/2010 01:20 PM, Ben de Groot wrote:
> 2010/1/24 Petteri Räty<betelgeuse@gentoo.org>:
>> On 01/24/2010 03:02 PM, Ben de Groot wrote:
>> Why should we keep redundant information in the list?
>
> How is that redundant?

Well, I doubt we'll get away from python in the system set anytime soon, 
but imagine the results of having a policy that anything that is a 
dependency of something in system needs to be in system.

Now the system set is three times larger than it is now.  There is also 
no easy way to tell whether something is in the set simply because it is 
a dependency.  Then in the future if something is no longer a dependency 
it will be installed on every gentoo system unnecessarily.

Sure, we can clean things up every once in a while, and maybe even 
automate that, but what would be the point.

The whole reason we have dependency management in our package managers 
is so that you don't have to worry about details like what package 
requires what.  Package managers shouldn't make it trivial to 
accidentally remove a dependency in an unsafe manner

Rich

Re: [gentoo-dev] emerge -C eselect-python disaster

[Arttu V.]

On 1/24/10, Benny Pedersen <me@junc.org> wrote:
>
> should not be marked as system ?
>
> it removes python-wrapper and this remove python link from
> /usr/bin/python linked to /usr/bin/python-wrapper so all portage does
> not work after this, but i solved it with a quickpkg from another host
>
> my dump question why is it not listed as a system pkg when it really
> seems so important ?

Nearly identical question was mulled over in a discussion last spring
over at gentoo-user list. Scan for "ARGH I uninstalled python" in the
archives if you are interested.

IIRC there was a suggestion to make the system set dynamically grow to
contain all of the required dependencies of the packages explicitly
listed in the system set, but I'm not sure if it went anywhere.

Anyways, the current contents of @system cause all kinds of surprises,
for example to FEATURES="buildsyspkg" users who rely on the feature
without realizing how small (and even "incomplete") @system actually
is.

-- 
Arttu V.

Re: [gentoo-dev] emerge -C eselect-python disaster

[Dale]

Arttu V. wrote:
> On 1/24/10, Benny Pedersen <me@junc.org> wrote:
>   
>> should not be marked as system ?
>>
>> it removes python-wrapper and this remove python link from
>> /usr/bin/python linked to /usr/bin/python-wrapper so all portage does
>> not work after this, but i solved it with a quickpkg from another host
>>
>> my dump question why is it not listed as a system pkg when it really
>> seems so important ?
>>     
>
> Nearly identical question was mulled over in a discussion last spring
> over at gentoo-user list. Scan for "ARGH I uninstalled python" in the
> archives if you are interested.
>
> IIRC there was a suggestion to make the system set dynamically grow to
> contain all of the required dependencies of the packages explicitly
> listed in the system set, but I'm not sure if it went anywhere.
>
> Anyways, the current contents of @system cause all kinds of surprises,
> for example to FEATURES="buildsyspkg" users who rely on the feature
> without realizing how small (and even "incomplete") @system actually
> is.
>
>   

I just picked a random reply here.  My $0.02 worth.  If I try to remove 
portage itself, I get this:

root@smoker / # emerge -Ca portage

 >>> These are the packages that would be unmerged:
 * Not unmerging package sys-apps/portage-2.2_rc61 since there is no valid
 * reason for portage to unmerge itself.

 >>> No packages selected for removal by unmerge
root@smoker / #

It appears you can't even remove portage at all.  Now call me silly, 
couldn't it be said that removing something that would prevent the 
package manager from working constitute a little warning?  After all, 
most likely the person is not thinking clearly that day and most likely 
doesn't REALLY want to do this.

Is there not a way to at the very least post a warning and then ask a 
'are you sure' question like it does with the -a option?

It's just that as a newbie ages ago, I did this too.  I didn't realize 
that it was a nasty boo boo until afterwards. 

< dale crawls back under his rock >

Dale

:-)  :-) 

Re: [gentoo-dev] emerge -C eselect-python disaster

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 323 bytes --]

On Sunday 24 January 2010 00:12:39 Benny Pedersen wrote:
> it removes python-wrapper and this remove python link from
> /usr/bin/python linked to /usr/bin/python-wrapper so all portage does
> not work after this, but i solved it with a quickpkg from another host

sounds a bug that should be filed so it can be fixed
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] emerge -C eselect-python disaster

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 578 bytes --]

2010-01-24 22:15:17 Mike Frysinger napisał(a):
> On Sunday 24 January 2010 00:12:39 Benny Pedersen wrote:
> > it removes python-wrapper and this remove python link from
> > /usr/bin/python linked to /usr/bin/python-wrapper so all portage does
> > not work after this, but i solved it with a quickpkg from another host
> 
> sounds a bug that should be filed so it can be fixed

There's already bug #268724.
Anyway, app-admin/eselect-python probably will have to be added to system
set for a suggested feature for EAPI="5".

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]