cloud-init-dev team mailing list archive

[Wesley Wiedenmeier <wesley.wiedenmeier@xxxxxxxxx>]

Since there is additional work that can be done to improve the build system, this branch and this merge proposal will be used for development. Below is some of the discussion on bddeb for reference.


> >> * creating the tarball..
> >> I think what we want to do here is:
> >> a.) make-tarball on "this side"
> >> b.) modify bddeb to be able to just create a debian/ dir
> >> either
> >> i.) have it create the orig tarball and a debian.tar.gz
> >> into a provided (empty) output dir.
> >> ii.) have it just create the debian.tar.gz and we create
> >> the tarball example of doing that
> >> http://paste.ubuntu.com/23870964/
> >> c.) move the tarball and debian dir over, extract tarball,
> >> extract debian/
> >> d.) mk-build-deps --install .... debian/control
> >> e.) dpkg-buildpackage
> >>
> >> doing this should mean we do not have to 'install additional
> >> build deps' but rather just have mk-build-deps do the right
> >> thing.
>
> >I had been trying to avoid modifying anything outside cloud_tests,
> >but adding the --debian-tar-only option in bddeb definitely does
> >simplify this. This may be a useful feature in general for debugging
> >cloud-init builds that do not work or doing custom deb builds, as
> >going through the template system can be inconvenient.
>
> >This also avoids having to go through a source repo in case the
> >current version of cloud-init in tree has different deps from the
> >one in the source repo.
>
> > Using dpkg-buildpackage instead of debuild may be quicker too.
>
> Yeah, it makes the build much simpler in the container. I'm tempted
> to further improve bddeb to list what packages need installing even,
> then we could drop the mk-build-deps and equivs ... but that is not
> necessary now. The complexity in that comes really from the obnoxious
> 'python3-pyflakes | pyflakes (<< 1.1.0-2)'
>
> in package/debian/control.in

Yeah, I kinda like the idea of bddeb to handle build deps entirely. That may
make things simpler for users who want to build as well since there have been
lots of questions on irc about how to build packages. We should probably add
more documentation on cloud-inits build system at some point as well.

> >> * when building with dpkg-buildpackage or debuild, good to
> >> allow setting DEB_BUILD_OPTIONS=nocheck (which will not run pep8 and
> >> nosetests)
>
> >Nice, I didn't know that was an option. Lets us avoid the additional
> >build deps step easily, since that was mostly to avoid failing because
> >testing stuff wasn't there.
>
> There is info at https://bugs.launchpad.net/cloud-init/+bug/1652329
> on what the plan here is... ultimately, package build wont run pep8, but
> would still run nosetests and useful to be able to not run them.

I do like the idea of dropping pep8 in the build, since the actual source used
for the builds whill have already been checked.

> >> * i think the above path means we do not depend on deb-src lines.
>
> >The switch back to ubuntu daily will handle that, but this also
> >avoids going through source repo at all which can be nice if a local
> >change adds a new build dep.
>
> And simply use of mk-build-deps would too..
> I know i'm kind of over-doing this, but i really like a "build a deb"
> thing that just can be easily used, and very ideally could even
> re-use an existing container, so i dont have to go through the apt-get update
> stuff there... so ultimately, i'd like something that just checks deps
> and builds and installs packages (and apt-get update) if needed.

I definitely like 'build a deb' as well, just to simplify the current build
system. I think it makes sense to pull the bddeb part of this merge into a
separate branch and continue to develop it further as well. It may be good once
kvm platform is supported to add an option to build there as well for users
building not on a system with lxd.
-- 
https://code.launchpad.net/~wesley-wiedenmeier/cloud-init/+git/cloud-init/+merge/314496
Your team cloud init development team is requested to review the proposed merge of ~wesley-wiedenmeier/cloud-init:integration-testing-invocation-cleanup into cloud-init:master.