linaro-infrastructure-stakeholders team mailing list archive

[Scott Bambrough <scott.bambrough@xxxxxxxxxx>]

On Thu, 2011-01-27 at 17:22 -0500, James Westby wrote:
> 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.

I'm not sure a single u-boot-linaro package is feasible.  The u-boot
binary contains SoC/board specific instructions.  How are you proposing
this happen?

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

It's not.  Going to a lot of work to accomplish this is ridiculous for a
tool that is only likely to be used to build our evaluation images.

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

I don't see the benefit of having the u-boot filename in the config
really.  Why doesn't the u-boot deb just install it in an expected
place.  The only reason I can see is to provide an override.

Scott
-- 
Scott Bambrough
Technical Director, Landing Teams