Upstream releases: update release upgrade paths #8569
Conversation
WalkthroughUpdated upgrade target mappings in four distribution config files (data-only):
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (4)
🚧 Files skipped from review as they are similar to previous changes (4)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
11
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (4)
config/distributions/focal/upgrade(1 hunks)config/distributions/jammy/upgrade(1 hunks)config/distributions/noble/upgrade(1 hunks)config/distributions/oracular/upgrade(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: leggewie
PR: armbian/build#8357
File: config/boards/qcom-robotics-rb5.conf:88-88
Timestamp: 2025-07-04T18:33:19.873Z
Learning: In the Armbian build system, package transitions in Debian/Ubuntu don't happen uniformly across all releases. For example, the transition from plasma-workspace-wayland to plasma-workspace occurred in newer releases like trixie (Debian testing) around July 2024, but older releases like jammy (Ubuntu 22.04) still maintain the original plasma-workspace-wayland package. Release-specific package availability must be considered when updating package references.
🔇 Additional comments (3)
config/distributions/oracular/upgrade (1)
1-1: Oracular → Plucky upgrade enabled (24.10 → 25.04). LGTM.Matches expected forward path after Oracular EOL.
config/distributions/jammy/upgrade (1)
1-1: Confirm upgrade target precedence from CSV order.If the upgrader prefers the first entry, Jammy defaults to Noble (LTS) over Plucky (interim). Verify this is intentional.
config/distributions/noble/upgrade (1)
1-1: Noble → Plucky added. LGTM.Keeps fastest forward path current.
There was a problem hiding this comment.
I believe this change is wrong, but I might also misunderstand the semantics of this code. In any case, you cannot upgrade directly from noble to plucky, you have to pass through oracular first. The only time you can skip a release in an upgrade is when going from LTS to LTS.
It defines possible upgrade path. The rest of the logic is in
You can, works, but there is of course no guarantee of success. That everything will work. Here LTS - new LTS, oldstable - stable ... that is important. The rest is experimental anyway. |
You can do all kinds of things, including shooting yourself in the foot with a shotgun among other things. You can also ignore a "you can't" that was supported by a reference to the relevant documentation saying so. But I have to wonder why you all so often do these kinds of things that will you get in trouble, @igorpecovnik ? |
|
APT is "advanced" but this is what we have. We don't have build-in function to (auto)reverse in case things go south ... distribution upgrade is troublesome / critical operation by default, LTS or non LTS, but people still wants to do it. During my testings I had success with Debian minimal and troubles with Ubuntu LTS minimal ... but this also don't tell anything. Now. We can ignore and keep elitist position (which is also wrong as Ubuntu Jammy - Noble upgrade had many broken dependencies and force fix was needed, while Debian upgrade went smooth) or say: "it is experimental feature, use at your own risk" - similar to kernel changing. |
|
Oh my! I have to ask, did you actually read the source I gave? https://help.ubuntu.com/community/UpgradeNotes I thought you are actually aware of this and the source wasn't even needed, but I am not so sure anymore. Again, why insist on a quirky way that the upstream you rely on clearly says is "not supported"? I just don't get you. Why are we even arguing? |
igorpecovnik
force-pushed
the
rel-upg
branch
from
5f29a24 to
d0a47a4
Compare
igorpecovnik
added
Ready to merge
Description
Since Ubuntu Plucky was introduced, we have to provide possibility to upgrade to that.
How Has This Been Tested?
Checklist: