[LEDE-DEV] fixing of image file names

[Matthias Schiffer]

On 12/12/2017 11:01 PM, Jonas Gorski wrote:
> On 12 December 2017 at 21:03, Jo-Philipp Wich <jo at mein.io> wrote:
>> Hi Piotr,
>>
>> my rough idea was to somehow tie the manifest generation to the "define
>> Device/*" macros present in the image building code because there you
>> have all required information in a central place:
>>
>>  - unique board identifier
>>  - image name / build steps
>>  - default package selection
> 
> I also think this is the easiest to achieve way for creating a way to
> lookup board_name => image_name.
> 
> We already define BOARD_NAME or SUPPORTED_DEVICES for many devices, we
> just need to set these consistently for all targets. Then we can
> easily create a manifest based on that.
> 
> That way we also have no restrictions on how we name the images; what
> is part of the images etc.
> 
> 
> Regards
> Jonas
> 
> P.S: We should also deprecate one of these for the other, we don't
> need two different variables for the same purpose.

Note that board_name -> image name does not always work on ar71xx, where
multiple different "equivalent" models share the same board_name, but have
their own image files with different magic numbers in the header
(especially for TP-Link devices). Enforcing that incompatible images use
different board_name would be a way to fix this, but it would increase
redundancy in /etc/board.d/*.

In Gluon (LEDE-based mesh framework) we have resorted to basing the image
selection of our autoupdater on the "model" rather than the "board_name"
(except for x86, where "model" is set arbitrarily, and we always select the
same image). At the moment this is realized by a deterministic sanitization
of the model name, which is then used as image name (we also have a
manifest, so it is actually not a hard requirement of our solution that
image name and model name match, just how we do it at the moment.)

Regards,
Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20171212/172c9811/attachment.sig>