Re: [PATCH 3/4] kde.org.eclass: Handle src_unpack for live ebuild Corrosion here

Andreas Sturmlechner posted on Sat, 06 Jun 2026 01:09:35 +0200 as
excerpted:

> +# default.  For live ebuilds, if both cmake.eclass and cargo.eclass are
> +# inherited, deal with potential Corrosion.

So this is my chance to ask (as a user already dealing with it in 
kdeplasma-addons), just how far is this "corrosion" likely to spread?

I'll avoid the rant but... let's just say I'm glad I continue to maintain 
locally the ebuild/eclass auto-patching infrastructure (/etc/portage/
patches idea applied to the gentoo tree and overlays, but taking simple 
sed-script dropins too) I had to hack up locally to keep no-semantic-
desktop working during the period gentoo/kde dropped support for that.

As of my last update I had to first (earlier) apply an /etc/portage/
patches/kde-plasma/kdeplasma-addons/wd40.patch (yeah I liked the name when 
I saw it some months ago and appropriated it for my kdeplasma-addons 
patch, tho AFAIK I'm not actually using anything else from that project) 
patch to punt the find corrosion and add-subdir(kdeds) lines in the 
upstream CMakeLists.txt, then latter when gentoo/kde caught up, do a 
corresponding sed dropin to kill the cargo inherit in the kdeplasma-addons 
ebuild (fortunately easy enough...).  Nothing else I have installed "live" 
seems to be doing it yet (well as of my last update), however.

But that this is being added to the eclass not just the one ebuild 
indicates you expect there's going to be more of these to deal with, which 
leave me wondering just how far this "corrosion" is going to spread...  
and whether I need to think again about possibly switching desktops if it 
gets bad enough. A pointer to some upstream list thread discussing their 
"corrosive" plans would be wonderful! =:^)

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