Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Ed Bartosh <ed.bartosh@linux.intel.com>,
	openembedded-core@lists.openembedded.org,
	Patrick Ohly <patrick.ohly@intel.com>
Subject: Re: [PATCH v5 1/2] image creation: support converting masked types
Date: Fri, 29 Jul 2016 15:29:30 +0100	[thread overview]
Message-ID: <1469802570.9142.74.camel@linuxfoundation.org> (raw)
In-Reply-To: <6b6fbba91ea7ac508bc8f8c53287ac90bdcff1b7.1469799731.git.ed.bartosh@linux.intel.com>

On Fri, 2016-07-29 at 16:44 +0300, Ed Bartosh wrote:
> From: Patrick Ohly <patrick.ohly@intel.com>
> 
> Conversion to vmdk/vdi/qcow2 is also useful for other base images
> types, not just for .hdddirect. This can be achieved by definining
> them as conversion commands and relying on the conversion chaining
> to convert arbitrary base images.
> 
> For this to work when the base image gets created by a masked image
> type, the additional conversion commands now get executed in a
> do_image_complete prefunc.
> 
> With all of that in place it becomes possible to remove the special
> purpose code for vmdk/vdi/qcow2 types from image-vm.bbclass and
> several other classes. This has (intentional!) implications on the
> valid IMAGE_FSTYPES and the file suffices: now
> "hdddirect.vmdk/vdi/qcow2" must be used as IMAGE_FSTYPES to select
> the
> former special-case types "vmdk/vdi/qcow2", and the image files and
> links will also have the extra .hdddirect suffix.
> 
> This is intentional because it makes it makes it possible to
> distinguish between virtual machine images created from .hdddirect
> and
> those created from other base images.
> 
> The new support for virtual machine images can also be combined with
> compression, thus making it possible to create image files for
> publication in compressed format, for example with:
>   IMAGE_FSTYPES = "hdddirect.vdi.xz"

I'm afraid I really don't like this. The direction this code has taken
is to separate out the different steps into clearly identifiable tasks.
This was due to strong user feedback that nobody could figure out what
was going on. This change starts to merge them all back together,
hiding them in a prefunc of a task which is just horrible.

I haven't looked in detail at the problem thats being attempted to be
solved here but this doesn't look like a good approach at all and takes
us backwards rather than forwards.

So, sorry, but no.

Cheers,

Richard



  reply	other threads:[~2016-07-29 14:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29 13:44 [PATCH v5 0/2] mage creation improvements Ed Bartosh
2016-07-29 13:44 ` [PATCH v5 1/2] image creation: support converting masked types Ed Bartosh
2016-07-29 14:29   ` Richard Purdie [this message]
2016-07-29 14:36     ` Richard Purdie
2016-07-29 14:58       ` Ed Bartosh
2016-07-29 13:44 ` [PATCH v5 2/2] image.bbclass: rename COMPRESS(ION) to CONVERSION Ed Bartosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1469802570.9142.74.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=ed.bartosh@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=patrick.ohly@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox