Enable the user to blacklist packages/package files during the build.

[cmacq2]

This change introduces two new environment variables:

• BLACKLIST_PACKAGES containing a whitespace separated list of package names to blacklist
• BLACKLIST_PACKAGE_FILES containing a whitespace separated list of package file names to blacklist.

This allows the user to create a customised on-off build using a pre-existing board directory as template. This change complements the whitelisting functionality inherent in setting PACKAGES as an environment variable before starting the build.

[dlech]

How often would someone use this instead of creating a custom board configuration? I think it is quite likely that this could cause as many problems as it solves, especially when you are omitting an entire package file. The hooks depend on certain packages being installed, so if they are blacklisted without modifying/removing the hooks as well, you will get errors.

My preferred way of doing things is that if you want a one-time custom image, use brickstrap shell or if you want to build a custom image more than once, copy the board configuration directory and modify it.

[cmacq2]

It's a high level feature with clear semantics. Of course you can shoot yourself in the foot, but if you take time to set up your package files properly (i.e. split off various 'features' into their own files) it can work really nicely for building multiple variants of the same configuration easily.

For example you can often grab things like DD-WRT in various flavours for a particular board, from "base" to "full fat" images. With the blacklisting functionality integrated something similar is easy to setup using brickstrap as well (using environment variables).

I'm also interested in checking that brickstrap can run without QEMU for 'native' builds or for non-ARM architectures (aarch64 in particular).

This combination would be particularly useful in the context of being able of testing a rootfs as a native VM or as a systemd-nspawn container (machinectl import rootfs.tar), as well as being able to reuse the rootfs configuration for various different target boards (if you take care to split board specific packages off into their own package files and set up environment vars).

[dlech]

OK. I see where you are going with this now.

Originally, in polystrap, boards shared common configuration using symlinks. I didn't like this so much because 1) if you change a default, it changed all the boards, which may not be boards you are familiar with and 2) it made it difficult to copy a board configuration directory without breaking symlinks. So, I took that out and now have three (soon to be 4) very similar board configuration directories for ev3dev, which is less than ideal.

So, I like where you are going, but I think we can do better than the environment variables that you have proposed here. What if we made it so that a board configuration directory had more than one config file for different "flavors"? The config files opt in to the package groups and hooks that are needed for that flavor. I think we would need to add an additional set of hooks that are run before the configure-packages to account for small differences in the root files. With this, to make a one-off, now you only have to copy a config file instead of the whole board configuration directory. What do you think?

Regarding non-32-bit-arm architectures, I think we just use the existing ARCH variable from the config files to pick the correct qem-user-static (or none at all). But you should open a separate issue for that.

[cmacq2]

I've create a new issue for this related discussion. I think that if we do this, we still want to be able to blacklist packages, so these variables make sense not just as environment variables but also in the context of setting them from a config value.

With that in mind I think you should merge in this PR so the work can be re-used in context of more exciting follow-up PRs resulting from issue #17

[cmacq2]

So what do you think now it's fixed? It would be a good thing to integrate this before I start working on a tentative implementation of issue #17

[dlech]

Looks good to me. I'm going to go ahead and merge this one since it is trivial, but then I'm not going to accept any pull requests until I get an ev3dev release done. Based on the number of issues I've been running into, could take me a week or so. :tired_face: