[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#929214: release.debian.org - Add package constraint for cloud images



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


Reply to: