fix(lifecycle): return correct base when using devel for build-base

[syu-w]

get_effective_base() should not return "devel" and pass it to the PartsLifecycle(), which make the parts think the coreXX is "devel". Thus checking the wrong path for dynamic linking.

LD_LIBRARY_PATH=...:/snap/core24/current/lib:/snap/core24/current/usr/lib:...
become
LD_LIBRARY_PATH=...:/snap/devel/current/lib:/snap/devel/current/usr/lib:...
which not exists.

Fix: #4508

[codecov-commenter]

Codecov Report

Attention: 8 lines in your changes are missing coverage. Please review.

Comparison is base (ffbdabf) 89.20% compared to head (191ea36) 89.19%.
Report is 18 commits behind head on main.

Files	Patch %	Lines
snapcraft/remote/git.py	22.22%	7 Missing ⚠️
snapcraft/projects.py	83.33%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4523      +/-   ##
==========================================
- Coverage   89.20%   89.19%   -0.01%     
==========================================
  Files         321      322       +1     
  Lines       21759    21826      +67     
==========================================
+ Hits        19410    19468      +58     
- Misses       2349     2358       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mr-cal]

Nice work finding the problem. Just a question about craft-parts.

[mr-cal]

👍

[sergiusens]

I don't understand why we are loosing the abstraction, it seems like the but is in get_effective_base

[sergiusens]

Can you also target the hotfix/8.0 branch?

[mr-cal]

So if I understand the failing spread test correctly, for a project with the following definition,

base: core24
build-base: devel

we want to pass the base of core24 to craft-parts and the base of devel to craft-providers. The problem is that get_effective_base() is not a one-size-fits-all solution for this scenario.

What do you think of adding "core24": bases.BuilddBaseAlias.DEVEL to this mapping? This would require us add more validation logic here so that

base: core24

still does not work. (and would give us an opportunity to raise a better error than the current KeyError that gets raised)

[mr-cal]

Ack, I'm sorry I linked to the wrong validator and misled you.

What I meant is that we need a validator that ensures this is still not allowed:

base: core24

I think you can add a new validator along the lines of if base == "core24" and not "build-base"?

Once the core24 snap is available on beta channel, we can remove this validator.

[mr-cal]

👍