linaro-infrastructure-stakeholders team mailing list archive
-
linaro-infrastructure-stakeholders team
-
Mailing list archive
-
Message #00043
Re: [proposal] Hardware packs v2
On Thu, 27 Jan 2011 22:37:12 +0100, Loïc Minier <loic.minier@xxxxxxxxxxxxx> wrote:
> On Thu, Jan 27, 2011, Guilherme Salgado wrote:
> > I don't think it's a lot of work, but it is work that won't necessarily
> > take us any closer to achieving what we want. I agree it should be
> > done, but I think it has lower priority than everything else that is
> > essential to achieve our goal: having board-specific detail in hwpacks.
>
> It solves two problems related to board data: you don't need to store
> the u-boot filename relative to rootfs in linaro-media-create's
> BoardConfig database, since you just read the u_boot field from the
> hwpack. So for instance the problems we had with files moving to
> different location would have been avoided.
The u_boot field /could/ reference a file in the rootfs after installing
all the packages, so it is not /required/ for the hwpack to ship the
u-boot file outside the package.
> The second problem it solves is support for multiple files in the same
> .deb, I think we've put a glob in place which would break if it matches
> multiple files. I'd like us to fix this because I would like to move
> from u-boot-linaro-$board packages to a single u-boot-linaro package to
> avoid package proliferation (we're about consolidation ;-)
I think that's a problem which is easy to avoid whichever approach that
we take.
> > However, further down you have a good point that if we were to do this
> > change later, it'd probably require a format bump, so I'm happy to
> > include it here.
>
> Ok cool; I think the above points might also help justify the need for
> this field
They justify the need to identify the u-boot file explicitly, I don't
think anyone would argue the utility of that.
What I believe that Guilherme is questioning is whether it is worth our
effort to stop installing the u-boot package in addition to setting up
the bootloader.
To be more concrete, as you were earlier, there are two schemes we could
have, the one you outlined:
hwpack config: u-boot package, and filename within that package
hwpack-create: download package, extract file, put it in hwpack,
include filename in metadata.
hwpack-install: install u-boot file based on metadata
or a second scheme:
hwpack config: u-boot package as it is now (just part of the list of
packages), and filename /relative to the rootfs/
hwpack-create: download package and put it in the hwpack as it does
now, include filename from config in the metadata.
hwpack-install: install packages as it does now, then install u-boot
file using the filename in the metadata, relative to the rootfs.
The second is clearly less work, as it is only a slight change from what
we have now (one new config entry, copied to the metadata, finding the
u-boot file based on the metadata rather than a find command.)
However, it may be worth doing the first, if it is the goal to stop
installing the u-boot package on the image. Is that the goal? What is
the justification for that?
Thanks,
James
Follow ups
References