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

Andreas Sturmlechner posted on Wed, 10 Jun 2026 00:04:52 +0200 as
excerpted:

> On Dienstag, 9. Juni 2026 06:14:27 Mitteleuropäische Sommerzeit Duncan
> wrote:
>> 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...
> 
> There is certainly no grand upstream plan to corrode everything.

Thanks.  That's good to read. =:^)

> Devs will always use what gets their job done though, and Corrosion
> is the necessary glue between CMake and rust/cargo.

Rust/cargo would be where that rant I omitted would be aimed.  I 
appreciate the security aspect but (as a different recent thread 
discussed) I'm evidently not the only one frustrated with the forced 
static linking and repeated should-be-unnecessary rebuilds, which has me 
staying away from it in general to the extent possible.  Indeed, corrosion 
is just a minor tool in the bigger picture; I'm not blaming it in the 
least.

> There are two other packages making use of it for some time, that
> we haven't been able to implement in packaging yet for lack of
> the eclass integration: akonadi-search and kdepim-addons.

kdepim and the mid-kde4-era akonadi-shark-jump's another rant, tho it's 
water long under the bridge now.  That's (still) the reason I haven't had 
anything kdepim on my systems since then, however, which in turn is why 
those two packages haven't affected me.

Anyway, /very/ releaved to read they don't have some plan to corrode near 
all of kde as I was fearing might be the case.  A package here or there 
can be dealt with.  Thanks again.

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