Thinking about it some more I think we have some problems and we should strive to have two features:
- it should be possible to build the
core snap with precisely the content we want, including precisely the set of new things we want (e.g. new library but old snapd or new snapd but nothing else changed)
- the customization layers (something that is not snapd and not merely an existing Debian package) should be unified for sanity, testability and comprehensibility.
I think we have either of those today.
If we revisit the goal to build the core snap and think about what we want to have in it, where it is built and how we can customize that we may come to a way to understand and design this better.
Let me propose a totally naive view of the situation:
- let’s have one project / repository that has a script that takes packages from the archive (or a directory or something like that), unpacks them and performs some customization on top.
- that project can keep version mapping (eg.
- that project can keep file filters (e.g.
rm -rf /usr/share/man, those can be imperative or declarative, whatever is easier for now)
- the project can contain a declarative list of things we want initially (e.g the root filesystem directories, permissions and owners)
- the project can also contain a directory with files that can be referenced by the previous list, e.g.
This should be all nice to build / test with snapcraft (perhaps using a custom plugin or using the make plugin and some scripts)
What do you guys think?