Move ubuntu-core-config from bzr to github

device
21

Sorry for asking, I just want to make sure I didn’t miss anything, so:

  • github.com/snapcore/core gets renamed to core-build?
  • github.com/snapcore/core-config stays as core-config?
22

that will be a mess to maintain since apart from the build scripts we still need to roll debs for the rest …
i.e. if we ever want auto-bulds of the deb packages (once we move away from the PPA) that will be in our way

23

Please no. This is unhelpful fragmentation for something that is really very close together. I bet those are all very small repositories with tiny files. We can keep whatever we have elsewhere consuming them as usual (independently) even if they are a single source code repository.

24

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. libfoo==1.2-3ubuntu2)
  • 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. /usr/lib/os-release content.

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?

25

for the various reasons mentioned in the private chat we had i object this …

can we please first just have a usable GH tree for ubuntu-core-config to soon have some writable-path changes ready that other teams wait for ?

re-doing the build env completely from scratch in a way that it still works with all ubuntu-isms and expectations (seeds, initrd integration, bits like ubuntu-fan support for running core in clouds, cloud-init integration etc etc) is a bigger change we can do in preparation (even in parallel to the current setup) for 18.04 but this will require good planning and some spare man-weeks to properly implement.

26

I think you are right in having something now and making sure we don’t neglect things and leave them pending for too long but we should also know where we’re going with this.

My point with the idea post was to discuss what we want to build and then plan how we want to get there. I think agreeing on those points will let us figure out how to put things together and where they should live on GitHub

27

@ogra Given that you’ll need to have source code moved regardless, can we please move this to snapcore/core-build/config at least? It’s okay to move other things there later, but let’s set the stage already.

28

i assume you mean snapcore/core/config … this wont work because during the core build live-build creates a config dir and links and copies bits and pieces there (the snapcore/core/ branch is also the toplevel dir of the build by default)

i guess snapcore/core/defaults might work though, this name isnt used by anything at build time (even though we lose the ability to build the deb in LP automatically by moving the source to a subdir, but we can solve that later i guess)

29

No, I really meant what I said above and in my messages before that.

30

@zyga-snapd Can we please do the rename, and move the content into a “config” directory or something else similarly approrpriate that prepares ground for this repository to receive the remaining content discussed above in the future?

31

oh, thats completely fine with me then i understood you wanted to have everything (build scripts, config and initrd bits) inside the same tree. if it is snapcore/core-build/config (and respectively snapcore/core-build/initrd) and snapcore/core stays untouched this is indeed fine

1 Like
32

I did the move inside the repository but I think I no longer have permissions to rename the repository itself. You will have to do that.

33

Renamed to core-build.

@ogra @zyga-snapd Would be good to have at least a short summary there explaining what this is.

34

Thanks! We’ll handle this. I’ll add a README.md file and do all the other massaging with @ogra :slight_smile: