On Mon, 23 Aug 2010 17:06:18 +0200, Alexander Sack <asac@linaro.org> wrote:
> 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.

The big problem I see is knowing which hwpacks should supercede all
others. Doing it by name makes sense for upgrades, but there could be
many that could install a kernel.

Yeah. hwpacks should have a unique id in their meta info. In that way you can figure this.

Maybe this doesn't actually matter, but my suspicion is that it will.

> 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.

I think that's fine. The spec is just confusing as it suddenly starts
discussing it in the middle.

good. whatever is easiest.

> 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.).

That's upgrades of the packages, not upgrades of the hwpack.

exactly.

> > 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.

Ok, tags are deferred from the initial implementation. Once we have some
experience using them we will be able to define the user interaction
much better.

Thanks. Thats fine.

> > 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.

Does that information have to go inside the hwpack. What would display
that information? What would behave differently?

The canonical meta info like this should go into the hwpack itself. On top we would also want to have that in the hwpack filename, so its obvious without introspection in the download.