Refactor cmake install and package definitions

[Woazboat]

• Use implicit default values where possible
• Simplify cmake install targets via GNUInstallDirs module
  • Installation directories for binaries, libaries, etc... are set automatically according to their target type
• Define components for install/package targets
  • Allows building separate packages for binaries and development headers (*-dev package)
• Rename included modified libxml++ to differentiate it from original libxml++

[mmd-osm]

OSM operations wants to go ahead with Ubuntu 24.04 for the time being and only move to Debian at a later point in time. This in turn means that cpack has only low prio now, since we would continue using Ubuntu Launchpad for packaging and shipping PPAs to OSM production.

[tomhughes]

That was intended more as a general comment on our strategy, that in the short term we are likely to upgrade machines to 22.04 simply because moving them to Debian requires a reinstall which is significantly more complicated while new hardware would get Debian.

That said as the web frontends are duplicated we may well want to move them to Debian at some point because we can do that in a staged manner without disrupting service.

[mmd-osm]

So there's some update in https://osmfoundation.org/w/index.php?title=Operations/Minutes/2024-06-27#%22OSM_PPA%22_work_approval

Minutes say "CGImap is blocking us moving with the six front ends.". I don't really know what this is about, maybe @Firefishy knows more?

[Firefishy]

Minutes say "CGImap is blocking us moving with the six front ends.". I don't really know what this is about, maybe @Firefishy knows more?

We'd like a PPA like deb repo for Debian 12 with our own builds (with potential extra patches). A replica of like what we have for Ubuntu https://launchpad.net/~osmadmins/+archive/ubuntu/ppa

[mmd-osm]

Thank you for the quick reply, this makes sense to me. Where exactly is CGImap blocking you atm?

[Woazboat]

Afaik an apt/debian repo is more or less just a bunch of files on a http server, so that could potentially be selfhosted?

[tomhughes]

It is from the point of view of serving it, yes. The complicated part it seems is turning a bunch of debs into a working file tree to serve.

I'm used to RPM where you can chuck a bunch of rpms in a directory, run createrepo to create the metadata and then just serve that up but the Debian wiki page on doing the equivalent is about 3 miles long with about 30 different ways of doing it none of which seem to be anything like that simple.

[Woazboat]

I just played around with https://www.aptly.info/ a bit and it seems fairly easy to use. [^1]

# Create a repository
aptly repo create -distribution=stable -component=main -comment="Stable repository for openstreetmap-cgimap" openstreetmap-cgimap
# Add deb packages
aptly repo add openstreetmap-cgimap /path/to/deb/files/
# Publish the repository (local file path that can be served via http)
aptly publish repo openstreetmap-cgimap

Also works with multiple versions of the same package

# Add a new package version
aptly repo add openstreetmap-cgimap /path/to/openstreetmap-cgimap_0.12.34_amd64.deb
# Update the published files
aptly publish update stable

Or multiple distributions for separate testing/stable repositories

# Create a testing repository
aptly repo create -distribution=testing -component=main -comment="Testing repository for openstreetmap-cgimap" openstreetmap-cgimap-testing
# Add a development version to the testing repo
aptly repo add openstreetmap-cgimap /path/to/openstreetmap-cgimap_0.12.34_amd64.deb
# Move the package version from testing to the stable repo
aptly repo copy openstreetmap-cgimap-testing openstreetmap-cgimap openstreetmap-cgimap_0.12.34_amd64.deb

[^1]: Listed in https://wiki.debian.org/DebianRepository/Setup

[mmd-osm]

This is a bit funny. I tried out aptly pretty much at the same time, and also thought it could be a good starting point for further evaluation. Creating ".deb" files for Debian 12 should be feasible, since we're anyway running test cases + build binaries in a Debian Bookworm docker image.

[Woazboat]

All you need to do to create a .deb file is run make package. I actually have an additional patch that builds on this pull request (although it should also be possible without it) that uses the created .deb packages to install cgimap in the docker images. That also automatically takes care of installing the required runtime dependencies without having to list and update them all manually in the dockerfile.

https://github.com/Woazboat/openstreetmap-cgimap/commit/d499553211747d8df75cd6647d04769e03aa0c89

[tomhughes]

Thanks for the suggestion - we now have an aptly based repo live at https://apt.openstreetmap.org/ which has replaced our PPA in production.

[tomhughes]

Moving the frontends to Debian 12 or Ubuntu 24.04 is getting a bit more urgent so do you have any idea when you might be in a position to provide packages?

[mmd-osm]

Re-publishing the current 0.9.3 release for Ubuntu 24.04 should be easy and shouldn't take too much time (again on Ubuntu launchpad). I still haven't figured out all details for the new apt.osm.org. Falling back to Ubuntu launchpad seems like a safe bet at the moment. Would that be ok?

[tomhughes]

We don't have any support for publishing to apt.osm.org yet so for now just build the packages wherever and I can load them manually.

We'd probably prefer just to jump to Debian 12 but I realise that's probably a bigger ask than Ubuntu.

[mmd-osm]

Ok, good. It seems getting the build up and running for Debian 12 should have priority over anything Ubuntu related.

In https://github.com/mmd-osm/openstreetmap-cgimap/tree/test/381 I have tested this PR with some more changes to generate and deploy a .deb package for Debian 12, with unit tests enabled.

The resulting docker image has the .deb file stored underneath /app_deb. This directory could be copied to the host machine, and then uploaded to apt.osm.org. Unfortunately, the package signing topic is not covered at the moment, and needs to be fixed urgently.

I totally want to avoid building anything on a local machine and then uploading binaries to some random place (in particular without signing packages).

It would be good to automate more of this as part of GitHub actions and use some Package registry to store results. As we have discussed in some other issue, my collaborator role is way too limited to do the proper config. We either need zerebubuth for that, or move the whole repo elsewhere.

One thing that's likely possible is to store the .deb build artifact on GH actions: https://github.com/actions/upload-artifact or combine it with the release process, like in https://github.com/trstringer/azblogfilter/blob/master/.github/workflows/release.yaml

[mmd-osm]

Storing .deb packages as build artifacts seems to work in general: https://github.com/mmd-osm/openstreetmap-cgimap/actions/runs/10390754008 (note: that's a test build only!)