Hi Noah, On 03-04-2021 17:44, Noah Meyerhans wrote: > It is sufficient for the Depends packages to be available in the next > release. Unfortunately, our package handling goes per source package, not by binary packages. >> Should the current package in testing be released with bullseye if we >> don't update it? > > IMO, debian-cloud-images should never have been packaged in Debian in > the first place, given that there was no plan to maintain it in the > archive and that a "stable" packaged version of it bears only a passing > relationship to the cloud images we actually ship, but it's too late for > that. What do you mean with "it's too late for that"? We *could* (not saying we should) drop the package. > In an ideal world, the debian-cloud-images package in the stable release > would match what generates the images for that release. However, it > moves relatively quickly in order to keep up with changes implemented by > the cloud services, so that would require us to update the stable > package frequently. The ability to update cloud related packages for > this reason was discussed with the SRMs some time ago, and I understand > that they were supportive of allowing such updates in stable point > releases. Practically speaking, we've only ever applied this agreement > once, to update cloud-init in buster. > > If we can't keep the debian-cloud-images package up-to-date in stable > releases, then it should not be included. It's the worst of both worlds > and can only cause confusion for users. I'd be in favor of removing it > from buster, too, if that's the case, where it's most definitely out of > sync with what's generating the cloud images today. If the SRM's are fine with updating the package in stable, I'm happy to unblock it. I'll point them to this bug to have them weight in. Paul
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature