Control: retitle -1 Add key package for cloud images Hi,
On Sun, May 19, 2019 at 12:18:31PM +0200, Bastian Blank wrote: > To make your and our work easier, we would like to ask you to add a > package constraint for all the packages included into the official > Debianm cloud images. > > From what I read, the easiest way for you would be to specify a single > package as constraint, a package that depends on all the other binary > package we explicitely include in the images. > > I intend to add one binary package per architecture we currently build > images for: amd64, arm64 and ppc64el. The dependencies will be arch > dependent and auto-generated from our own list. > > The package would look like this: > > | Package: debian-cloud-images-packages > | Architecture: amd64 > | Depends: apparmor, awscli, chrony, cloud-init, cloud-initramfs-growroot, > google-compute-engine, grub-cloud-amd64, grub-pc, libpam-systemd, > linux-image-amd64, linux-image-cloud-amd64, openssh-server, python, > python-boto, python3-boto, sudo, unattended-upgrades, waagent > > Please acknowledge that such a package would be okay for using as > constraint. After that I'll upload that change. Constraints are only used to check installability of packages that britney wouldn't otherwise be able to check. This isn't necessary in this case. What you want is a source package that is added to the key packages list, to prevent auto-removal. If you create such a package, having a binary per architecture as you describe, should do what you want. It can be added to the list as soon as it is in testing. Please note that if some of the packages involved would cause serious issues for the release, we might still notify you that we would be forced to (manually) remove them if the issues aren't fixed. Also, just as a suggestion: if it is feasible, you could add an autopkgtest to that source to build (or even test) the cloud images. That would prevent migration to testing of packages that break your images. Cheers, Ivo