On Fri, Aug 20, 2010 at 10:26 PM, James Westby <james.westby@linaro.org> wrote:
Hi all,

Scott asked me to take a look at the hwpack spec:


I took the liberty of editing it somewhat to make the definition of a
hardware pack clearer, and remove some contradiction in the
implementation suggestions.

I have some questions about the goals of the spec though:

 1. Do we support installing more than one hardware pack on an image?

in theory yes, but practically I don't expect this to become a major use case. If it's easier assuming that there is just one in the first phase, lets do that.
 2. What is the purpose of the hwpack.deb that is mentioned in places?

this is scotts baby i think. personally i am fine without a hwpack.deb. I think the idea was that configs etc. like apt source lines accompanying the hwpack could be shipped in there. Personally I think its good enough to start with this meta info being optionally in the tarballs somewhere.
 3. Do we want to be able to pull in new versions of a hwpack on
 request, or should it just be a case of updating the image, with a
 hwpack-install call if you want to install a newer version that pulls
 in new packages?

we dont want to have magic that pulls a new hwpack at this stage. hwpack-install is used to install and upgrade from a local/remote-url that points to the hwpack tarball.

However, as (iirc) mentioned in the spec, a hardware pack optionally can also ship custom apt lines, so magic upgrades without a new hwpack tarball can happen for hwpacks that come with such a location (e.g. a ppa or a partner hosted apt repository etc.).

 4. Do we want to support cross-installation in any way?

yes, however, we will run the hwpack-install inside a armel chroot, so thats not a technical problem for the hwpack-install binary. The magic for that will probably happen in linaro-media-create.
 5. What are the use cases for tags? I can only see X/no X in the spec.

tags are low priority. It came up with an ability to not install parts of the pack (like no x drivers if you dont care about X in a headless install for instance.

Other tags I envision could tag packages according to what use case they support (e.g. multimedia) or whether its a free/proprietary etc.

 6. What are the use cases for support information?

We want to label hwpacks as "unsupported" or "community" so we can offer them to download on snapshots.linaro.org while sending a clear message that those are not official linaro hardware packs because they don't come from a linaro consolidated kernel tree for instance.


 - Alexander