Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
nicopace opened this issue Dec 29, 2017 · 1 comment
Open

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

nicopace opened this issue Dec 29, 2017 · 1 comment

Comments

@nicopace
Copy link
Member

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
Copy link
Member

p4u commented Jan 8, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants