search

apache / couchdb-pkg

Apache CouchDB Packaging support files
https://github.com/apache/couchdb-pkg
Apache License 2.0
29 stars 30 forks source link

Add nouveau sub-package #143

Open hennevogel opened 3 months ago

hennevogel commented 3 months ago

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 apache/couchdb-pkg#142

Checklist

hennevogel commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

nickva commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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:

https://github.com/apache/couchdb-pkg/blob/aa9f9c251c5325a2ab76ad53efeca9d10ad30c42/build.sh#L105-L128

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

janl commented 3 months ago

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?