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

Re: Official Debian image request: Google Compute Engine (was: Re: Please let's not talk about "clouds")

On Wed, Apr 24, 2013 at 02:54:36PM +0200, Lucas Nussbaum wrote:
> First, Nothing below is a definitive answer, either positive or negative.
> As you know, we don't have clear guidelines/policies for that question.
> I'm trying to get a better understanding first, and I'm open to changing
> my mind. :)

Right, thanks for starting this. We sort of discussed this on this list
for Amazon EC2 images, mainly because they've been the first major
public cloud provider offering "official" Debian images. I mentioned
"sort of" because the discussion had not been explicitly on
"guidelines", but we did discuss blockers for publications here --- in
particular I've raised a few of them.

I try below to recast them as more general guideline points, for your
(and this list) consideration.

> For "official Debian images", I think that the list of requirements
> should include at least:
> A) the image includes only software available in Debian

To be precise, I think this should be Debian *proper*, i.e. only the
main archive. Moreover, I think contrib and non-free should *not* be
enabled by default within the images.

More generally, we have a lot of defaults in the Debian images we
distribute for installation on actual hardware. To be thorough, we
should review those defaults and decide which of them are a must for
virtual images as well and which should be relaxed. But that would be a
tedious exercise. So, as an alternative, we should probably expect that
virtual images have the same content of non-virtual Debian images, and
that differences should be explicitly approved (by whom? no idea :-)).

This is very similar to what trademark policy usually require for any
sort of product. I.e. if the product is "substantially equivalent" to
what we call "Debian" elsewhere, then it can be called "Debian" by
others (in this case: cloud marketplace vendors), otherwise it will need
to be explicitly approved.

An alternative would be to have a testsuite that should pass before
being able to call something Debian. But we're nowhere near having
something of the sort, and I don't think it'd be a quick exercise to do

> B) the image generation process is controlled solely by Debian

I'm not sure if "solely" is tenable. I think for instance at the need of
cryptographically sign images, with keys available only to the public
cloud vendors. (This is, in fact, very similar to Secure Boot
situations.) We should probably expect that some steps are not redoable
by Debian, as long as we can inspect the produced images, or something

> C) the image is generated using tools available in Debian, or maintained
>    by Debian

That is fine, but note that the "or maintained by Debian" is a very
relevant "or". For instance, even only for traditional Debian images, we
have a lot of the infrastructure we use to make Debian which is not part
of Debian (e.g. dak). So, what does it mean "maintained by Debian"? Note
for instance that Anders' scripts to produce both EC2 and GCE images are
currently hosted in GitHub and that Anders is not a Debian Developer. I
totally *love* his work :), and I'd like it to qualify for producing
"official" images.

Stefano Zacchiroli  . . . . . . .  zack@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Attachment: signature.asc
Description: Digital signature

Reply to: