Hardware pack questions
asac at linaro.org
Mon Aug 23 17:14:18 BST 2010
On Mon, Aug 23, 2010 at 5:14 PM, James Westby <james.westby at linaro.org>wrote:
> On Mon, 23 Aug 2010 17:06:18 +0200, Alexander Sack <asac at linaro.org>
> > 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
> > 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
> > 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
> > 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.
> > > 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
> > 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
> > those are not official linaro hardware packs because they don't come from
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linaro-dev