This quote is from an old forum topic (but below question and download info is still open).
Is there now something that updates the systems of users that chose to set up a testing image, to follow the “stable” branch after the release (e.g. detect when bullseye is stable and then switch to generic “stable” sources?
We have the following in our apt configuration (/etc/apt/apt.conf.d/20freedombox-allow-release-info-change) currently:
// When release information such as 'Version' and 'Suite' change for a
// distribution changes, apt requires an explicit confirmation from the user.
// apt-get(8) specifies the reason for this prompt as ensuring that the user is
// prepared for the change. On a FreedomBox installation, as the system
// administration agent of the user, FreedomBox has to make this decision on
// whether the user is ready for the change. FreedomBox works to keep the system
// up-to-date and manages configuration changes for packages, data migration
// etc. Hence, accept all release information changes without a prompt.
//
// Without this, when a stable release is made, if the user was using that
// code-name before the release, then the system stop receiving updates and no
// new apps can be installed in FreedomBox. This happened in case of Buster
// release although Debian itself had some part in this. See:
// https://salsa.debian.org/freedombox-team/plinth/issues/1601
Acquire::AllowReleaseInfoChange "true";
This should solve the specific problem you highlighted. On top of that, @jvalleroy has done extensive work on upgrade from Buster to Bullseye. Help with more testing this is welcome.
We currently don’t have code to change ‘testing’ to ‘bullseye’ however.
Ok, thanks. So currently the testing image will continue to follow testing.
Actually, it might be preferable the other way around: To let the testing images and systems use only the codename (currently bullseye), so that what they get are only stabilizing upgrades until the official release, never early breaking transitions.
With the release they would need to get the security and backports repository added and all the sources lines be changed to “stable” instead of the specific code-name.
But maybe this could be implemented rather simply with the plinth backports package builds. (They would only come in after the release.)
It might just require one of these:
Then, as soon as the backports become available the first plinth package from the backports could change everything from “codename” to “stable”.
The underlying assumption is of course, that it would be good and viable to easily setup a system and test it with all the newer features by installing the testing images (say nearing the freeze), and still end up with a stable-proper system later on. For example, when it’s time to switch it online.
I don’t know how I could test what happens upon a stable release.
Nevertheless, I found this issue that seems very related:
So it looks like the testing images currently actually have “buster-backports” already enabled.
@sunil @jvalleroy: But “buster-backports” (the current stable) suggests to me that it will break when bullseye becomes stable with the next release.
On the other hand, maybe exactly this codenamed backports line can be part of a solution if a different approach is used:
Instead of freedombox systems doing (unattended) upgrades immediately after the release, maybe the updates of stable freedombox systems could be triggered by a (last) backports package to the then old-stable. When installed on the new old-stable it triggers the update (incrementing the codenames from old-stable to new-stable).
And on the released-testing, that last backports package just, well shouldn’t have to do much (besides switching over that backports line) if everything else was already pointing to the proper testing, and newly stable, codename.
Not sure why you think it will break. After bullseye release, buster-backports will be frozen, but not disappear.
Buster-backports need to be based on versions in testing, which will be frozen in the months leading up to the bullseye release.
The current implementation will handle updating the sources list for freedombox package (actions/upgrades · master · FreedomBox / FreedomBox · GitLab) to point to bullseye-backports. This will happen ~1 day after the dist upgrade to bullseye (because bullseye-backports repository already exists, even though it is empty).
The only thing missing is to update the sources list for apps (actions/upgrades · master · FreedomBox / FreedomBox · GitLab) but this has to be done after bullseye release. We won’t know which packages to take from bullseye-backports until later.
I’ll try to explain my thoughts after discovering the issue that mentioned that testing systems enable the buster-backports. I thought:
Having that backports line pointing to buster in testing currently makes the backports to stable buster work, without disturbing testing, thanks to older or equal versions and same priorities (the fixed bug above).
After the release buster-backports may still be technically there, but I think it won’t work for the new-stable (bullseye) to have a backports line that points to old-stable buster-backports (thus breaking with release).
And I thought, whatever mechanism fixes this should also be able to adjust freedombox testing systems to follow stable instead of staying on the testing branch, or the current release (bullseye) forever.
Now to your answer.
First, thanks for pointing out that the backports repository also gets frozen, it’s a good point that I didn’t account for in the approach for package triggered updates. So package driven updates might only be possible with https://fasttrack.debian.net/
But from your links, I see there already is a mechanism and it works differently.
I gather that the system’s sources list is expected to be configured to point to “stable” or “testing”. The system checks the codenames of the available stable and optionally testing repositories, and updates to any new codename if one becomes available. Correct?