Re: branching the debian-cloud-config repository for stable support
On Fri, May 08, 2020 at 04:29:16PM -0400, Noah Meyerhans wrote:
> Consider the following simple case. I'm working on packaging
> amazon-ec2-utils, which I'd like to add to the default installation once
> it's available. To do that today, I'll need to add release specific
> configs to package_config/EC2, or add EC2 specific stuff to
> package_config/{BULLSEYE,SID}. It's manageable, but clunky.
Please take a look at package_config/AZURE, where such a change was done
for cloud-init. While a bit verbose, I don't consider that clunky.
> When we
> start talking about config files that are specific to combinations of
> releases and/or architectures and/or cloud providers, it gets even
> worse.
With existing support we can AND two classes. Do you see some change that
would need three?
My problem with all of this is:
You are trying to optimize for something that happens now only the
second time now during this release cycle and also doesn't even need
workarounds to get right.
However you miss the whole lot of other changes that don't change how we
build stuff, but how we transport, modify and finalize images. And
there have been significant changes during this time period. Some of
them have been breaking changes. And a lot of them also needs to done
to the tools used for stable stuff.
So a typical change to not build stuff would now require
- merge into master and
- merge or cherry-pick master into buster and look out for stuff that
must not be merged.
Regards,
Bastian
--
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown
Reply to: