← Back to team overview

linaro-infrastructure-stakeholders team mailing list archive

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