search

libremesh / lime-sdk

LibreMesh software development kit
http://libremesh.org/
GNU General Public License v3.0
50 stars 36 forks source link

Have a per-community feeds.conf and release file #47

Open nicopace opened 6 years ago

nicopace commented 6 years ago

Lime-sdk allows to config a feeds.conf file where you can specify the feeds. For those added from a VCS you can specify a hash reference, a tag or a branch.

The feeds.conf defines the building environment parameters... so if you have a build environment that requires a different set of feeds, a different version of a feed, or a different source of a feed, you need to clone another env, and it is not persisted anywhere.

It would be great if we can add a FEEDS and RELEASE file in the root of a community profile that acts as a replacement of the feeds.conf base file and the release variable in the options.conf file. If that exists, it will build an environment based on those specs.

This could also help for reproducibility, because it will allow to generate exactly the same binary.

p4u commented 6 years ago

It adds extra complexity and implies important changes. Right now, the community is only used when cooking (packing and generating firmware). So the community concept is right now a customized collection of packages and files.

To add source feed support per community, cooker must know it in advance (when building but before cooking). So the feed is cloned and the packages included compiled.

Thus, these three steps are necessary for building a firmware for a specific the community. 

./cooker -f --community=blah
./cooker -b ar71xx/generic --community=blah
./cooker -c ar71xx/generic --community=blah

Right now, as cooker is designed, -f and -b are only needed once (per architecture) and -c can be used multiple times (once -b compilation has been executed).

So, your proposal changes the basic design of cooker. I'm not against it but it might require a heavy redesign of the code and also of the concepts.

An alternative (partial) solution would be to allow communities to specify a HTTP OPKG repository where the packages are already compiled (check file libremesh.repositories.conf ). That would fit with the current design of cooker cause this repositories are used ONLY when cooker (by ImageBuilder).