How to avoid upgrading an installed Python 2.7 package?

[segmentation-fault]

Hello all,

I am trying to upgrade an old system, but @world upgrade fails with

Code: Select all

emerge: there are no ebuilds to satisfy ">=dev-lang/python-exec-2[python_targets_python2_7(-),-python_single_target_python2_7(-)]".
(dependency required by "x11-themes/fvwm-crystal-3.2.3-r1::gentoo" [installed])

But I have masked x11-themes/fvwm-crystal:

Code: Select all

grep fvwm /etc/portage/package.mask 
# Stick with 2.6.5!
>=x11-wm/fvwm-2.6.6
# ...And since now fvwm-crystal-3.6.5 *requires* >=x11-wm/fvwm-2.6.9[png],
>=x11-themes/fvwm-crystal-3.6.5

So fvwm-crystal-3.2.3-r1 is installed, but all higher versions are masked:

Code: Select all

eix x11-themes/fvwm-crystal
[?] x11-themes/fvwm-crystal
     Available versions:  [m]3.6.5 [m]~3.7.1 {PYTHON_SINGLE_TARGET="python3_10 (+)python3_8 python3_9"}
     Installed versions:  3.2.3-r1(10:50:36 pm 04/01/2019)(PYTHON_TARGETS="python2_7")
     Homepage:            http://fvwm-crystal.sourceforge.net/
     Description:         Configurable FVWM theme with transparency and freedesktop compatible menu

My world file has these fvwm-related files:

Code: Select all

grep fvwm /var/lib/portage/world

x11-themes/fvwm-crystal
x11-themes/fvwm-themes
x11-themes/fvwm-themes-extra
x11-themes/fvwm_icons
x11-wm/fvwm

and all are installed fine in the versions that I like:

Code: Select all

[?] x11-themes/fvwm-crystal
     Available versions:  [m]3.6.5 [m]~3.7.1 {PYTHON_SINGLE_TARGET="python3_10 (+)python3_8 python3_9"}
     Installed versions:  3.2.3-r1(10:50:36 pm 04/01/2019)(PYTHON_TARGETS="python2_7")
     Homepage:            http://fvwm-crystal.sourceforge.net/
     Description:         Configurable FVWM theme with transparency and freedesktop compatible menu

[I] x11-themes/fvwm-themes
     Available versions:  0.7.0-r1 {gnome}
     Installed versions:  0.7.0-r1(10:51:05 pm 04/01/2019)(-gnome)
     Homepage:            http://fvwm-themes.sourceforge.net/
     Description:         A configuration framework for the fvwm window manager

[I] x11-themes/fvwm-themes-extra
     Available versions:  0.7.0
     Installed versions:  0.7.0(10:51:24 pm 04/01/2019)
     Homepage:            http://fvwm-themes.sourceforge.net/
     Description:         Extra themes for fvwm-themes

[I] x11-themes/fvwm_icons
     Available versions:  1.0
     Installed versions:  1.0(10:51:43 pm 04/01/2019)
     Homepage:            https://www.fvwm.org/
     Description:         Icons for use with FVWM

[I] x11-wm/fvwm
     Available versions:  2.6.5-r3[1] [m]2.6.9 {bidi debug doc gtk2-perl lock netpbm nls perl png readline rplay stroke svg tk truetype +vanilla xinerama}
     Installed versions:  2.6.5-r3[1](04:08:50 am 12/05/2020)(netpbm nls perl png readline rplay svg tk truetype xinerama -bidi -debug -doc -gtk2-perl -lock -stroke -vanilla)
     Homepage:            https://www.fvwm.org/
     Description:         An extremely powerful ICCCM-compliant multiple virtual desktop window manager

[1] My local overlay

Yet even this

Code: Select all

emerge --ignore-built-slot-operator-deps=y -vUDua --exclude "app-emulation/virtualbox x11-themes/fvwm-crystal $(grep -E -v '(^#|^$|^[ ]*$)' /etc/portage/sets/world-dead)"   @world

fails with the above message!

As you see, I explicitly exclude virtualbox and fvwm-crystal, since these are packages I have reasons to keep in their old versions. I also exclude a set (/etc/portage/sets/world-dead) that I constructed from packages of my world file that I know they don't have ebuilds anymore. I am willing to "emerge -av --depclean" any package that would appear as a blocker, in case it really is some old remnant - but the problem here is that I don't get past this python-exec2 message!

From my "user perspective" (which is my primary perspective when I do such things like updates - I do have others...) this is a bug. It seems that it focuses too early on the missing python-exec2 and outputs the message before it checks my exclude list.

But, before I open a bug for sys-apps/portage, I would like your opinion and would welcome any hints. What else shall I do to make portage NOT TOUCH my beloved, old, installed XY python 2.7 package and go on with the rest of the packages - other than "mask in /etc/portage/package.mask" and "exclude from the command line", as I have done?

Some info (although IMHO it is totally irrelevant - but since you will be asking for it anyway...):

Code: Select all

Portage 3.0.28 (python 3.8.12-final-0, default/linux/amd64/17.1/hardened, gcc-11.2.0, glibc-2.30-r8, 5.4.168-gentoo x86_64)
=================================================================
System uname: Linux-5.4.168-gentoo-x86_64-Intel-R-_Core-TM-_i7-6700HQ_CPU_@_2.60GHz-with-glibc2.2.5
Timestamp of repository gentoo: Sat, 22 Jan 2022 00:45:01 +0000

sh bash 5.1_p8
ld GNU ld (Gentoo 2.37_p1 p0) 2.37
app-misc/pax-utils:        1.2.5::gentoo
app-shells/bash:           5.1_p8::gentoo
dev-java/java-config:      2.3.1::gentoo
dev-lang/perl:             5.34.0-r6::gentoo
dev-lang/python:           2.7.18_p13::gentoo, 3.6.10-r2::gentoo, 3.7.7-r2::gentoo, 3.8.12_p1-r1::gentoo, 3.9.9-r1::gentoo
dev-lang/rust:             1.58.1::gentoo
dev-lang/rust-bin:         1.58.1::gentoo
dev-util/cmake:            3.21.4::XXXXXX
dev-util/meson:            0.60.3::gentoo
sys-apps/baselayout:       2.7-r3::gentoo
sys-apps/openrc:           0.42.1::gentoo
sys-apps/sandbox:          2.25::gentoo
sys-devel/autoconf:        2.13-r1::gentoo, 2.69-r4::gentoo
sys-devel/automake:        1.11.6-r3::gentoo, 1.12.6::gentoo, 1.13.4-r2::gentoo, 1.14.1::gentoo, 1.15.1-r2::gentoo, 1.16.4::gentoo
sys-devel/binutils:        2.33.1-r1::gentoo, 2.37_p1::gentoo
sys-devel/binutils-config: 5.4::gentoo
sys-devel/clang:           7.0.0::gentoo, 8.0.1::gentoo, 9.0.1::gentoo, 10.0.0::gentoo
sys-devel/gcc:             7.5.0::gentoo, 8.3.0-r1::gentoo, 8.4.0::gentoo, 9.3.0::XXXXXX, 11.2.0::gentoo
sys-devel/gcc-config:      2.5-r1::gentoo
sys-devel/libtool:         2.4.6-r6::gentoo
sys-devel/lld:             10.0.0::gentoo
sys-devel/llvm:            7.0.0-r1::gentoo, 8.0.1::gentoo, 9.0.1::gentoo, 10.0.0::gentoo
sys-devel/make:            4.3::gentoo
sys-kernel/linux-headers:  5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc:            2.30-r8::gentoo

[fedeliallalinea]

The x11-themes/fvwm-crystal-3.2.3-r1 support only python2_7 python target that is no longer supported by gentoo because python-2.7 is end of life.
This is not a bug because a new version of x11-themes/fvwm-crystal with python3 support exists, so if you want keep older version you should also take on the burden of maintaining and patching it.

[Hu]

--exclude is documented to prevent installing the excluded atom. It doesn't specifically say that the atom is not part of the dependency tree, though I can see why that might be useful.

I think you need to either upgrade the package or provide an ebuild that allows it not to be upgraded.

[segmentation-fault]

This is not a bug because a new version of x11-themes/fvwm-crystal with python3 support exists, so if you want keep older version you should also take on the burden of maintaining and patching it.

I will not do that, sorry. Not only because I lack the skills (I might go on and spend the next 6 months to acquire them, if I deemed it necessary, but then...here comes the second point), I also don't deem it necessary. It should not be necessary to ask the user to become the maintainer of his installed-but-end-of-life ebuilds! If this is really how Gentoo works, I have misunderstood it. I have always thought Gentoo was about choice. Such a requirement practically forces everyone to depclean everything that is not in the Portage tree, even if he does not intent to upgrade them, just to make portage overcome its internal shortcomings.

You might think that, just because a new version of x11-themes/fvwm-crystal with python3 support exists, this requirement is somehow justified. It is not. I have my reasons why I will NOT upgrade to a higher fvwm (note: I am saying fvwm, not fvwm-crystal! But a newer fvwm-crystal would need a newer fvwm too, so it's no-deal for both).

This is a typical situation where the system forces its shortcomings upon the user. The shortcoming is that portage is unable to look at my exclude list and think "O.K. you don't want me to deal with that package, I will leave it out of my considerations". Instead, it not only informs me of the missing python-exec2 - it stops there!

I should not stop. I know that, when and if I start some fvwm-crystal script, like

/usr/share/fvwm-crystal/fvwm/scripts/FvwmMPD/getprevdir.py

I will have to deal with python-exec telling me that it could not find an interpreter for it. I will then have to change the "shebang" of some rarely (if ever) used program of it, or...or...But let that be my problem when and if time comes. All I want now is to get past that message.

This should not be a problem for portage. If it is, I fail to see how - please explain. IMO it is a bug, not a feature.

[Hu]

The generally accepted design of Portage is that the system must be able to rebuild itself. If you want to rebuild with old components instead of upgrading, that is fine. However, it is not the responsibility of the Gentoo developers to ensure that any arbitrary point in history can be rebuilt using the latest tools. If you want to pin in history, then do it right. Stop syncing to newer versions of other tools, and use a consistent snapshot of that point in history. If you want to update some components and not others, then someone will need to keep those components compatible with each other. When you track tip for everything, the Gentoo developers take on that burden for you. If you want to mix and match pieces of history, then compatibility becomes your problem.

If the user isn't expected to assume maintainership of end-of-life ebuilds, who should? The Gentoo developers declared them end-of-life because they are not maintaining them anymore.

I think --exclude was added well after some other features. It's possible no one ever tested using it on an ebuild that cannot resolve its own dependencies properly, since best practice is not to create unsolvable dependency graphs.

[segmentation-fault]

I think you need to either upgrade the package or provide an ebuild that allows it not to be upgraded.

But, don't you see how contradictory this is? I shall provide an ebuild to portage (hmm...so far so good), only to allow an installed (but end-of-life) ebuild NOT to be upgraded?

Well, provide an ebuild because...people need to install it - yes, that is an honorable purpose (although it should not be forced upon the users). But to provide it for the sole purpose of NOT being upgraded? Just because portage coughs at its eclasses? Give me a break.

This is trying to bend the user around a stiff system. It should be the other way round - it is called software for a reason!

It is becoming all the more clear to me that this is a bug - call it a shortcoming, if you like. portage should be amended so that when it encounters a problem with an ebuild of an installed package that is on the exclude list, it should not consider the problem fatal. This may change the semantics of --exclude slightly (encompassing into exclusion also such packages) - but the change will be IMO to the better: I doubt we will find a user who feels that the current behavior, as described above, is "normal" (i.e. you exclude something, but it's not excluded because, technically, it's an upgrade and not a new install and that's "normal" - huh? ).

[segmentation-fault]

best practice is not to create unsolvable dependency graphs.

Of course. I would do all I could to "untangle" the dependency graph for portage. Exactly that is why I passed the offending package to my --exclude list. But portage did not take notice. That's a bug.

Above all - how did a Gentoo developer put it?... - it goes against the principle of least surprise.

[Hu]

I think you need to either upgrade the package or provide an ebuild that allows it not to be upgraded.

But, don't you see how contradictory this is? I shall provide an ebuild to portage (hmm...so far so good), only to allow an installed (but end-of-life) ebuild NOT to be upgraded?

Your installed ebuild imposes constraints on the dependency graph. You don't like those constraints. Therefore, you need to remove those constraints. You have three ways to do this:

• Remove the outdated package.
• Rebuild the package, at the same version level, with a custom ebuild that provides solvable constraints.
• Upgrade to a version from the Gentoo Portage tree where the Gentoo developers have already provided an ebuild with solvable constraints.

The first choice is obviously the easiest, but if you are using functionality from that outdated package, you may not want to remove it.

Well, provide an ebuild because...people need to install it - yes, that is an honorable purpose (although it should not be forced upon the users).

What should not be forced on users? Gentoo ebuilds exist to let the system avoid breaking things under you. You're welcome to rewrite the VDB to delete the constraints that serve as a safety net, but if you do, you'll probably have something break that the safety net would have prevented.

But to provide it for the sole purpose of NOT being upgraded? Just because portage coughs at its eclasses?

The Gentoo standard approach would be that you should upgrade. Trying to pin specific packages in the past, while the rest of the system moves forward, is not a scenario the developers spend hours to support. If that is how you want to use the system, then you need to spend those hours in their stead.

This is trying to bend the user around a stiff system. It should be the other way round - it is called software for a reason!

I don't understand what you want here.

It is becoming all the more clear to me that this is a bug - call it a shortcoming, if you like. portage should be amended so that when it encounters a problem with an ebuild of an installed package that is on the exclude list, it should not consider the problem fatal.

I said that the documentation does not promise the behavior you are requesting, and that your current usage is a scenario that was likely not well tested, because what you are doing is unusual.

This may change the semantics of --exclude slightly (encompassing into exclusion also such packages) - but the change will be IMO to the better: I doubt we will find a user who feels that the current behavior, as described above, is "normal" (i.e. you exclude something, but it's not excluded because, technically, it's an upgrade and not a new install and that's "normal" - huh? ).

On a re-read of your initial post, I now disagree more strongly with you. It looks to me like --exclude successfully prevented Portage from trying to upgrade/install the named package. Portage then panicked because, if you don't upgrade it, then you do need the old python-exec -- which you cannot get. Thus, you have a dependency conflict. You can solve this by not having any packages that need the old python-exec.

best practice is not to create unsolvable dependency graphs.

I would do all I could to "untangle" the dependency graph for portage.

Clearly not. If you really want to untangle this graph, the expedient solution would be aggressive use of emerge --ask --depclean until the conflicting packages were all gone. This may, in some cases, make the system less pleasing to use until the upgraded versions are available.

Exactly that is why I passed the offending package to my --exclude list. But portage did not take notice. That's a bug.

You can consider it that if you wish, but as I understand the documentation of --exclude, I disagree. You successfully excluded the package from upgrade. That's what that parameter does. If you don't want Portage to apply dependency consistency checks, you should disable dependency checking. You get to keep the pieces when that breaks, though.

[Goverp]

Is package.provided any use here, possibly combined with manually installing into /usr/local/ ?

[Hu]

package.provided will convince Portage not to try to install the named package. Using it without a manual install of the equivalent functionality will cause problems later, but if done in parallel with an install in /usr/local, that could work. However, since OP is deliberately retaining very old versions of things, he may not be able to build them for a manual install into /usr/local, if they cannot be rebuilt with current tools.

[segmentation-fault]

I don't understand what you want here.

I want portage to leave my installed fvwm and fvwm-crystal untouched, not consider them at all, continue with the @world upgrade as if these two did not existed. I have excluded them with --exclude but still, something causes it to complain. This should be possible without having to delete these two packages from the world file (which I am reluctant to do, I prefer to exclude them). There are other packages that are installed, do not have ebuilds anymore, are in the world file, and I can exclude them by putting them in my world-dead file and excluding all files from world-dead. Look at my very first post above. This is what I tried


emerge --ignore-built-slot-operator-deps=y -vUDua --exclude "app-emulation/virtualbox x11-themes/fvwm-crystal $(grep -E -v '(^#|^$|^[ ]*$)' /etc/portage/sets/world-dead)" @world


That is, I exclude all packages from /etc/portage/sets/world-dead that are not on comment or empty/space-only lines. Now, my /etc/portage/sets/world-dead contains 718(!) entries and portage does not complain about any of them - but it complains about my installed x11-themes/fvwm-crystal not having python-exec2! Who cares about this? I don't! I just want portage to move on!

[segmentation-fault]

Clearly not. If you really want to untangle this graph, the expedient solution would be aggressive use of emerge --ask --depclean until the conflicting packages were all gone. This may, in some cases, make the system less pleasing to use until the upgraded versions are available.

This looks so harmless - but is a BIG problem. "make the system less pleasing to use" - you say? I have refrained from posting my comments on fvwm in my /etc/portage.mask, because these are MY reasons and it's none of portage's business to mess with them, but here they are

Code: Select all

# Unfortunately, FVWM versions higher than 2.6.5 are problematic for me:
# 2.6.6 solves quite a lot of bugs and it would be very nice, if...
# ...yeah, if it were not buggy itself! Some nasty bugs regarding 
# windows that positioned themselves in weird places were not fixed
# until 2.6.7. But 2.6.7 drops a TON of good'ol' FVWM modules
# which I am not willing to deal with (it breaks my menus and 
# possibly my whole .fvwm2rc). The consequence is: stick with 2.6.5!
>=x11-wm/fvwm-2.6.6
# ...And since now fvwm-crystal-3.6.5 *requires* >=x11-wm/fvwm-2.6.9[png],
# I have to mask it too...
>=x11-themes/fvwm-crystal-3.6.5

So upgrading to fvwm 2.6.7 and later may make the system less pleasing to use, you say? I say it will make it unusable for me.

Something else may be at work here...I don't know what, but...it just doesn't make sense to me. Since there is no ebuild for my installed fvwm-crystal-3.2.3-r1 (the current versions available start at 3.6.5) how then does portage know that this installed version is missing python-exec2 and says what I posted at the start:

Code: Select all

emerge: there are no ebuilds to satisfy ">=dev-lang/python-exec-2[python_targets_python2_7(-),-python_single_target_python2_7(-)]".
(dependency required by "x11-themes/fvwm-crystal-3.2.3-r1::gentoo" [installed])

Where is this "dependency required by "x11-themes/fvwm-crystal-3.2.3-r1::gentoo" [installed]" recorded, if the ebuild for fvwm-crystal-3.2.3-r1 is not available at all to portage?

Could it be that we are looking a message that regards some other package (that portage will not say), having its origin only at fvwm-crystal? Some transitive-dependency kind of thing?

[pingtoo]

Code: Select all

emerge: there are no ebuilds to satisfy ">=dev-lang/python-exec-2[python_targets_python2_7(-),-python_single_target_python2_7(-)]".
(dependency required by "x11-themes/fvwm-crystal-3.2.3-r1::gentoo" [installed])

Where is this "dependency required by "x11-themes/fvwm-crystal-3.2.3-r1::gentoo" [installed]" recorded, if the ebuild for fvwm-crystal-3.2.3-r1 is not available at all to portage?

I believe it is store in /var/db/pkg/*

If you try

Code: Select all

cd /var/db/pkg
find . -type f -exec grep -H python-exec-2 {} \;

I am sure you can find the file you want.

[segmentation-fault]

Where is this "dependency required by "x11-themes/fvwm-crystal-3.2.3-r1::gentoo" [installed]" recorded, if the ebuild for fvwm-crystal-3.2.3-r1 is not available at all to portage?

I believe it is store in /var/db/pkg/*

If you try

Code: Select all

cd /var/db/pkg
find . -type f -exec grep -H python-exec-2 {} \;

I am sure you can find the file you want.

Indeed! I used ripgrep (rg for short, from sys-apps/ripgrep):

Code: Select all

rg -F python-exec-2 /var/db/pkg/x11-themes/fvwm-crystal-3.2.3-r1/

and it immediately showed:

Code: Select all

/var/db/pkg/x11-themes/fvwm-crystal-3.2.3-r1/RDEPEND
1:>=dev-lang/python-2.7.5-r2:2.7 >=dev-lang/python-exec-2:2/2=[python_targets_python2_7(-),-python_single_target_python2_7(-)] >=x11-wm/fvwm-2.6.5[png] virtual/imagemagick-tools || ( >=x11-misc/stalonetray-0.6.2-r2 x11-misc/trayer ) || ( x11-misc/hsetroot media-gfx/feh ) sys-apps/sed sys-devel/bc virtual/awk x11-apps/xwd

So that's where it comes from. Now I need to find a way to tell portage to ignore it and continue - is there a --move-on option somewhere?

[pingtoo]

is there a --move-on option somewhere?

English is NOT my first language, so I am guess what you mean --move-on, I think you can use --keep-going

For an old system update, I recommend you review NeddySeagoon's HOWTO Update Old Gentoo

Think of Gentoo as toolset, There are methods to get your system however you want.

Plan for multi-steps Incremental update. Many think of Portage as only live at moment, therefor you should catch up, but there is git repo remember all the history You can catch up at your own pace.

[Hu]

The easiest way to satisfy Portage here would be emerge --ask --unmerge fvwm-crystal. The second easiest would be to provide an ebuild in an overlay for this version, without the unwanted dependency. The third easiest, and potentially rather dangerous, way is to edit the RDEPEND data for that VDB entry to forget that the dependency exists. To do that, remove the offending atom(s) in the file. This one is unconditional, so it is easy.

I don't think --keep-going will help here. That tells Portage to persevere after a build fails and build as much as it can, rather than stopping on the first failure. OP has not yet gotten even one build to start, due to the dependency conflicts.

[segmentation-fault]

Hu and all,

regarding the first solution (practically to depclean the package):

Code: Select all

>>> Calculating removal order...

>>> These are the packages that would be unmerged:

 x11-themes/fvwm-crystal
    selected: 3.2.3-r1 
   protected: none 
     omitted: none 

As you can see, no package depends on it. However, I find it wrong to be forced to follow this "solution". This is actually no true solution. It just forcefully eradicates the symptom.

A true solution would be what I asked for: if the user has set an already installed package in the --exclude list, portage should not bother him with Python problems that this installed package might have.

In this example, the situation is even more strange: as you see, no package depends on fvwm-crystal. So why care so much?

And it becomes hilarious if we ponder for a moment: what is actually this fvwm-crystal? It is a theme package. And what is a theme? A collection of images. So why does it need python-exec2? Because it has two scripts that do something (I don't know and I don't care) and they need Python 2. But I will probably never use them. If I want to use a theme from the package, I will take its images, put them where they have to be and will enjoy my new window decorations. Why am I tortured with something irrelevant at a point where I cannot afford spending my time on decisions about the fate of a theme?

I understand that a "dependency on Python 2" is an "all-or-nothing" proposition - either the package depends on Python 2, or it does not. There is no "it depends if the user cares, but it does not depend if he does not". Again, here I would say if the user has put it to the exclude list, it is a clear sign that he does not care and this wish should be respected.

Anyway, the second and third solutions are indeed ways to circumvent the problem. But they pass the burden to the user and we should keep them for more difficult problems - not this. This should have been taken care by --exclude - but it has not been.

I will let you know how I resolved this (I am currently busy doing incremental updates, since @world blocks this way), so many thanks to you and all so far for the explanations and help.

[Hu]

In this example, the situation is even more strange: as you see, no package depends on fvwm-crystal. So why care so much?

It is in @world, so the @world set depends on it. You are updating @world, so its dependencies are fair to consider.

As documented, --exclude does not work the way you wish it did. Arguing with us is not the right way to change how --exclude works.

[segmentation-fault]

As documented, --exclude does not work the way you wish it did. Arguing with us is not the right way to change how --exclude works.

Indeed, I should file a bug/feature extension request. But, as I said at the very start, I wanted to hear your opinion (and have it documented here) first.

[sam_]

Given Python 2.7 support is mostly gone, Portage is rightly telling you that it can't proceed because newer versions of the various Python toolings are not tested with - and lack support for - Python 2.7.

It is not trying to frustrate you for no reason. If this package had satisfiable dependencies, it would still work, even though it was removed.

I would not recommend --unmerge though, instead --depclean.

[Hu]

Generally, I agree that --depclean is preferable since it is safer. However, the documentation states:

Code: Select all

As a safety measure, depclean will not
              remove any packages unless *all*  required  dependencies  have  been  re‐
              solved.  As  a  consequence, it is often necessary to run emerge --update
              --newuse --deep @world prior to depclean.

I have had a similar experience to that warning: using --depclean on a system with certain unresolved dependencies just fails, with a request to do a full update first. OP is using a system that is severely out of date, so I would not be surprised to find that the safety logic on --depclean prevents using it here.

My opinion is that we should not offer a convenient way for users to subtly break their installed packages. An option to selectively ignore dependencies on some packages might be useful, but it definitely should not be the default. OP has repeatedly complained that the existing mechanisms which reduce dependency analysis are too hard to use or find, so I don't see much value in adding another dependency suppression option if it is well hidden, and I think it would be bad not to make it well hidden.

[sam_]

Generally, I agree that --depclean is preferable since it is safer. However, the documentation states:

Code: Select all

As a safety measure, depclean will not
              remove any packages unless *all*  required  dependencies  have  been  re‐
              solved.  As  a  consequence, it is often necessary to run emerge --update
              --newuse --deep @world prior to depclean.

I have had a similar experience to that warning: using --depclean on a system with certain unresolved dependencies just fails, with a request to do a full update first. OP is using a system that is severely out of date, so I would not be surprised to find that the safety logic on --depclean prevents using it here.

My opinion is that we should not offer a convenient way for users to subtly break their installed packages. An option to selectively ignore dependencies on some packages might be useful, but it definitely should not be the default. OP has repeatedly complained that the existing mechanisms which reduce dependency analysis are too hard to use or find, so I don't see much value in adding another dependency suppression option if it is well hidden, and I think it would be bad not to make it well hidden.

I think depclean with an argument (the thing to remove) may often succeed when a regular one won't, but yeah, point taken.

And agreed.

[segmentation-fault]

Given Python 2.7 support is mostly gone, Portage is rightly telling you that it can't proceed because newer versions of the various Python toolings are not tested with - and lack support for - Python 2.7.

It is not trying to frustrate you for no reason. If this package had satisfiable dependencies, it would still work, even though it was removed.

My plan with all those Python 2.7 packages was to keep them - and look at them later. portage forces me to take hard decisions at a point in time where I would definitely prefer to NOT have to take them. Surely, if i want to use those packages at all, I will have to find a solution - but please not now! Put yourself in my position: it's day 11 of the update. This means: for 11 days now, I have stopped working, I don't do anything else - and have been pulling my hair with this update! The psychological "mode of operation" in such situations is "I want to get through this with the least pain possible" - but portage takes such an adamant position regarding consistency of the dependency graph, that rather leads to maximum pain possible.

In the meantime, I have come to understand that portage will complain about each and every one such packages, no matter what I do. I thought --exclude was (also) for such purposes - Hu is right, it is not, it simply does not take effect.

All this has forced me to rethink how I view Gentoo. When I came to Gentoo long time ago, I was reading that the world file is the set of packages that I want to keep installed on my system. This is wrong! Or I got it wrong. Or both. The truth is:

The world file is the set of updatable and runnable packages that you wish to have installed in your system.

Now, for you, this maybe nothing new, because you are used to this view of the world file. For me it is a change of perspective.

It turns out, if I still want to view my world file as "the set of packages that I want to keep installed on my system" - then I should not be trying (in vain!) to update @world!. Because, simply put, my world file is not updatable and contains "not runnable" (e.g. Python 2.7-based) programs. Instead of trying the de facto impossible, I should think about set strategies, as Hu suggested.

I should define a world-updatable set and, from then on, update @world-updatable - NOT @world!

Of course, and this is a fine point that evaded me most of the time, updatable and runnable are qualities that are dynamic, not static - they are defined anew each time we sync!

Since I set out to define world-updatable and tried to update that one, things have started looking promising again. It's too early to report, but as soon as I get some breakthrough, I will write my experience down.

Thinking of it on day 11, and with the backing of the preceding discussion, all this looks somehow "natural": portage updates sets. It does not "update world". "world" is a name you give to a set. Now, I want portage to be "permissive" and portage insists on being "adamant", regarding dependency consistency and runnability.

Where is actually the problem? Define a different set, one that by construction will not contain any problematic package - and let portage be adamant with its update on that one! It will (it must!) succeed - by construction! [1]

You see, once again, philosophy is at the basis of everything - it all boils down how you view...world!

---

[1] Well, almost. I still get complaints about installed packages (from other, currently disabled, overlays), even if these do not belong to world-updatable. So far, I've had only one such case - we'll see how it goes...

[Section_8]

In principal, I don't see how using sets here is any different than just adding packages you don't want updated to /etc/portage/package.mask. Either way, as long as the packages being regularly updated and the packages that are locked at some release share any common dependencies, you will eventually run into a problem like this, where one of those common dependencies needs to be updated, but the update is blocked by one of those "locked" packages.

[eccerr0r]

and look at them later.

If not now, then when?
Have to pay the piper at some point for free software that you can not or will not update on your own.

Don't get me wrong, I was a bit ruffled by the loss of Chirp from portage, but it's really chirp's fault for not keeping up with the python updates.
As long as I've been using Gentoo there are a bunch of other packages that got bumped which is quite unfortunate but the alternative to self-maintain was a higher cost...

The 2.7 migration has been known for years at this point. Should have known this was coming a long time ago. Also since this happened I have a serious disdain for python because of the serious API change and shun python whenever I see it. Grr.