So we now have this new shiny repository where various packages related to the core snap will end up in. I was looking at it and I’d like to discuss possibility of some low-hanging-fruit gardening, specifically:
removal of debian/bzr-builddeb.conf
renaming the package from ubuntu-core-config to perhaps core-config or similar
renaming anything referring to ubuntu-core to core
renaming anything referring to snappy to snapd
I’m somewhat wary of doing that in absence of any CI though. Opinions?
this will require changes in multiple places outside of this package and will also break the naming scheme for ubuntu images (each official ubuntu image has some ubuntu-$flavour-config) i am not sure this is a good idea, especially since this package contains all the bits that make it a usable “Ubuntu Core IoT” image.
this package is branding and configuration for producing bootable images along with the initramfs-tools-ubuntu-core package. as long as we use it to create the Ubuntu Core embedded/IoT product we should still keep the branding in the package name.
totally with you on that one, along with this we eventually also need to drop all reference to system-image, i.e. /etc/system-image/writable-paths should just become /etc/writable-paths eventually (but this also requires non trivial changes on the initrd side)
long term we should also move hook bits that do not need build time integration from live-build/hooks in https://github.com/snapcore/core into this package.
the hooks were often used because it is quicker to add modifications there but they should not be used for general configuration, branding etc. normally.
Problem with “core-config” is that it means something else on the context which is closest to it. Every time people hear or talk about “core config” inside this community, they’ll be talking about something else.
Yeah, core-config is a pretty unfortunate name. I think there’s a naming scheme where xxx-config is a configuration preset for package xxx. How about ignoring that (since nobody would need this package apart from our image build infrastructure) and just calling it appropriate, e.g. snapd-device-config.
EDIT: actually, why don’t we merge this into snapd? We already ship “device” units that only get used in a core/all-snap system. We’d just ship some more than now?
well, it is the package used to ship the default configs for the Ubuntu Core product … as all other ubuntu products the package name is $flavour-config … like we do have -config packages for all other flavours we do have an ubuntu-core-config binary package for the Ubuntu Core product. I dont see a reason to change that in any way unless there are plans to drop the product name or change it to “Snapd Device”
My only point is that this package is only consumed by us to build the core snap. I don’t think we support installing this package on another system and having it “work”.
that doesnt change its purpose, it is a branding and configuration package for a certain product and follows the general defaults for other ubuntu products
note that i really only talk about the binary name of the deb here … i obviously already surrendered (with the loss of being able to do any auto-builds now) to move the source tree to a subdir in a github tree with a random name.
and on a side note … this package will have to be merged back into its archive equivalent eventually, we can not use the PPA forever and will eventually have to switch to SRUs for it … which means we can not just randomly rename it
You said that before, and we precisely explained the reason why it should be changed above. Let’s please never talk about core-config anywhere near snapd without it meaning the configuration of the core snap.
i’m talking about ubuntu-core-config only … with the emphasis on ubuntu-core which is a flavour used in the ubuntu archive, build system, launchpad, marketing, PR, etc … just like ubuntu-studio-config or xubuntu-config exist (or the respective -artwork packages) as binary deb packages … the package name follows a generic ubuntu standard used by all flavours like Ubuntu Core is one …
Also note: if you check the package content you will notice that it it is only useful when the core snap is actually used as a booted rootfs, not when it is used as execution environment for snap packages on classic systems.
