Add nouveau sub-package

[hennevogel]

Overview

This package adds the nouveau.ini config file and restarts the couchdb service if installed.

I would need help with the content of nouveau.ini as I know nothing about it. I'm just a packager from the fediverse...

GitHub issue number

Fixes #142

Checklist

• Code is written and works correctly;
• Changes are covered by tests;
• Documentation reflects the changes;

[hennevogel]

It's also a bit iffy as you decide if you build nouveau by presence of a nouveau file in your build root. This is not really how you do this in RPM land. This is how you do it: https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html

[nickva]

It's also a bit iffy as you decide if you build nouveau by presence of a nouveau file in your build root. This is not really how you do this in RPM land. This is how you do it: https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html

Thanks @hennevogel. That setting is a compatibility setting to build couchdb 3.3.3 series patches which don't have nouveau. We could probably make it unconditional and always build it if we build main / 3.4 series. Then if we need to make a 3.3.3 package we can create retroactive tag/branch on couchdb-pkg to build it.

[hennevogel]

That setting is a compatibility setting to build couchdb 3.3.3 series patches which don't have nouveau.

yeah I figured as much...

We could probably make it unconditional and always build it if we build main / 3.4 series.

That would be "just" a commandline switch (--with nouveau) wherever you decide how you call rpmbuild. I guess in build.sh.

I already said it on mastodon: You desperately need a build system that can handle multiple distros / repositories! </shameless self plug> 😉

[hennevogel]

Let me see if I can add this build condition to your spec, stay tuned...

[nickva]

You desperately need a build system that can handle multiple distros / repositories! </shameless self plug> 😉

Ha! that's cool, will take a look!

I've been eyeing fpm for a while as something simpler perhaps, do you think it would fit our use case?

[hennevogel]

@nickva I'm super biased of course as OBS is (one of) my life's work but this repository here sounds to me as you want your users to get binary packages from you, to install from a repository for their flavor/version of distribution, with their distributions tooling. This is exactly what OBS is built for. The rest is cross-distro packaging (the things that happen in your Makefile, like different package names/versions for different distros/architectures etc.) which is also pretty much figured out and boils down to a couple of ifs.

OBS is used since decades to do exactly that for projects that ship a small (kubernetes/a couple) and large (Linux Distributions / >20K) number of binaries together in a repository.

But I just glanced at Makefile and build.sh I don't want to pretend to know what you do here 😸

[nickva]

Thanks for explaining, @hennevogel

But I just glanced at Makefile and build.sh I don't want to pretend to know what you do here

Heh. The general idea is to build packages on top of ci/build images, which are in turn built with docker buildx for all the supported OS types, versions and architecture flavors. For building packages we use build.sh only.

This is the combinations we support:

DEBIANS="debian-bullseye debian-bookworm"
UBUNTUS="ubuntu-focal ubuntu-jammy"
CENTOSES="centos-8 centos-9"
XPLAT_BASES="debian-bullseye debian-bookworm ubuntu-focal ubuntu-jammy centos-8 centos-9"
XPLAT_ARCHES="arm64 ppc64le s390x"

The x86_64 is the base arch. Then the XPLAT ones are the "extra" platforms we support. Not all combinations work. Some architectures have broken java bits, some broken JIT bits for Erlang etc.

The building starts in:

couchdb-pkg/build.sh

Lines 105 to 128 in aa9f9c2

	build-all-couch() {
	rm -rf ${SCRIPTPATH}/pkgs/couch/*
	for plat in $DEBIANS $UBUNTUS $CENTOSES; do
	build-couch $plat $*
	done
	for base in $XPLAT_BASES; do
	for arch in $XPLAT_ARCHES; do
	# nouveau packaging fails on ppc64le OSes
	# see https://github.com/apache/couchdb-pkg/issues/140
	echo " **** base:${base} arch:${arch} ****"
	if ! [[
	( ${base} == "centos-8" && ${arch} == "arm64" ) ||
	( ${base} == "centos-8" && ${arch} == "ppc64le" ) ||
	( ${base} == "centos-9" && ${arch} == "ppc64le" ) ||
	( ${base} == "debian-bullseye" && ${arch} == "ppc64le" ) ||
	( ${base} == "debian-bookworm" && ${arch} == "ppc64le" ) ||
	( ${base} == "ubuntu-focal" && ${arch} == "ppc64le" ) ||
	( ${base} == "ubuntu-jammy" && ${arch} == "ppc64le" )
	]]; then
	CONTAINERARCH="${arch}" build-couch ${base}
	fi
	done
	done
	}

And ends up with packages in the pkgs directory which are then uploaded to Apache JFrog instance.

[janl]

nouveau.yaml is part of the CouchDB source distribution: https://github.com/apache/couchdb/blob/main/rel/nouveau.yaml

it will have its {{ placeholders }} set to actual values during make release (https://github.com/apache/couchdb/blob/d0cf54e1ef5c7e67fe08c29c5e80a1b77ca614e7/rel/reltool.config#L148) and placed into etc/nouveau.yaml in the release tarball. — can we reference it from there rather than adding it here?