l-m-c doesn't support future live-build3

[Tom Gall]

When linaro upgrades from live-build3-a21 to live-build3-a34, the tar format will change. This causes an incompatibility as the binary-tar.tar.gz file has a different format.

Specifically the root file system is now contained in binary/boot/filesystem.dir

For the sake of trivia, the debs installed into the file system are located in binary/pool

[Tom Gall (tom-gall)]

This bug is marked critical as we will be switching to this new level of live-build3 as part of our change over to oneiric.

[Tom Gall (tom-gall)]

This can be as simple as changing linaro-media-create on line 110 to

110 ROOTFS_DIR = os.path.join(TMP_DIR, 'binary/boot/filesystem.dir')

However this would not be backward compat with the older rootfs organization from live-build.

Adding a simple existence test for say binary/etc, if that fails you know you have the new format and to use the directory above is probably the way to go... I think it might also be wise to add an version file in the binary-tar.tar.gz.

Thoughts?

[Fathi Boudra (fboudra)]

@Tom: Release team should be subscribed.

[Mattias Backman (mabac)]

On Tue, Oct 11, 2011 at 2:22 AM, Tom Gall <email address hidden> wrote:
> This can be as simple as changing linaro-media-create on line 110 to
>
> 110     ROOTFS_DIR = os.path.join(TMP_DIR, 'binary/boot/filesystem.dir')
>
> However this would not be backward compat with the older rootfs
> organization from live-build.
>
> Adding a simple existence test for say binary/etc, if that fails you
> know you have the new format and to use the directory above is probably
> the way to go...    I think it might also be wise to add an version file
> in the binary-tar.tar.gz.

The binary-tar.tar.gz is the output from our builds, right? If you say
that we could leave a version file in it, possibly we could even put a
metadata file there? That could just explicitly specify the
binary/boot/filesystem.dir part to be joined with TMP_DIR.

This would be in line with the hwpacks V2 work where we have made sure
that control over paths and other specifics are handed to whoever
creates the hwpack. Could this be the start of images having metadata
as well?

>
> Thoughts?
>
> --
> You received this bug notification because you are subscribed to Linaro
> Image Tools.
> https://bugs.launchpad.net/bugs/872007
>
> Title:
>  l-m-c doesn't support future live-build3
>
> Status in Linaro Image Tools:
>  New
>
> Bug description:
>  When linaro upgrades from live-build3-a21 to live-build3-a34, the tar
>  format will change. This causes an incompatibility as the binary-
>  tar.tar.gz file has a different format.
>
>  Specifically the root file system is now contained in
>  binary/boot/filesystem.dir
>
>  For the sake of trivia, the debs installed into the file system are
>  located in binary/pool
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linaro-image-tools/+bug/872007/+subscriptions
>

[Loïc Minier (lool)]

On Tue, Oct 11, 2011, Mattias Backman wrote:
> The binary-tar.tar.gz is the output from our builds, right? If you say
> that we could leave a version file in it, possibly we could even put a
> metadata file there? That could just explicitly specify the
> binary/boot/filesystem.dir part to be joined with TMP_DIR.
>
> This would be in line with the hwpacks V2 work where we have made sure
> that control over paths and other specifics are handed to whoever
> creates the hwpack. Could this be the start of images having metadata
> as well?

 +1! :-)

--
Loïc Minier

[Tom Gall (tom-gall)]

Yes, we could easily have a metadata file included with the generated tarballs, just a matter of what all we would like in such a file.

META_VERSION:
SEED:
ROOTFS_DIR:
ROOTFS_PACKAGES:
ROOTFS_FILE_MD5SUMS:
DIST:

Hmm any other field you can think of that would be useful?

[Mattias Backman (mabac)]

REQUIRES_X:
MIN_PARTITION_SIZE:

[Loïc Minier (lool)]

On Tue, Oct 11, 2011, Mattias Backman wrote:
> REQUIRES_X:

 Is this about Xorg packages? Is there a way we could abstract it in
 something more generic and reusable?

 e.g. the rootfs would say Requires: xorg-support and the hwpack would
 say Provides: xorg-support. This could be reused for e.g. gstreamer
 support.

--
Loïc Minier

[Mattias Backman (mabac)]

On Tue, Oct 11, 2011 at 2:40 PM, Loïc Minier <email address hidden> wrote:
> On Tue, Oct 11, 2011, Mattias Backman wrote:
>> REQUIRES_X:
>
>  Is this about Xorg packages?  Is there a way we could abstract it in
>  something more generic and reusable?
>
>  e.g. the rootfs would say Requires: xorg-support and the hwpack would
>  say Provides: xorg-support.  This could be reused for e.g. gstreamer
>  support.

Absolutely. I'll create a blueprint for this and we can continue the
discussion and talk about it in Orlando.

In the meantime, I'll do the simple fix that Tom suggested for the next release.

[Mattias Backman (mabac)]

https://blueprints.launchpad.net/linaro-ubuntu/+spec/linaro-platforms-p-image-metadata

[Dr. David Alan Gilbert (davidgil-uk)]

A set of fields stating the total RAM+swap would be interesting; running the Ubuntu desktop images on the machines with 256MB ram and no swap OOMS quite easily, so defaulting to some SWAP when using the chunkier images on smaller boards would be nice.

Dave

[Tom Gall (tom-gall)]

Successfully tested the branch.