Hi everyone,
thanks for your feedback and great questions!
Are you doing a similar workflow to current backports, where you take commits from nixpkgs’
masterbranch and cherry-picking them to your own, creating your own commits of changes from nixpkgs, or something else?
Since our support model is a bit different from what is done with the current backports we are not cherry-picking but creating our own commits. We are providing patch updates for software that is packaged in 24.05.
This is easiest to explain if you imaging a software following the semver versioning model with a MAJOR.MINOR.PATCH versioning. For CTRL-OS we will default to providing PATCH updates and might provide MINOR updates in some cases. But we will generally not do MAJOR updates.
i have to assume there is a subscription fee coming… i just didn’t realize this would be wide open at this point - are you able to clarify roughly at what point these channels will be no longer be publicly available?
We are planning to provide public channels and cache with updates to the release-small set at least until the next release (26.05). After that our plan is to provide a public channel and cache for 26.05, but only provide updates for 24.05 to our paying customers.
Since I assume you are not going to support all packages in nixpkgs for 5 years, are you still trying to figure out what the scope will be?
There is mention that the SBOM-generation tool can also be used to tell them which packages are actually in use, with the implication that their support set will be guided from there.
As noted above we provide updates to the release-small set and customers can pay us to support additional packages (e.g. by providing us with an SBOM).