common: Debian/Ubuntu packaging doesn't mark /etc/containers/containers.conf as a conffile

@lsm5 @rhatdan My external view - please take with a grain of salt. You (~RedHat) are in the slightly unusual situation of being both the authors of this software, and also the packagers of it for various distributions. That makes sense when the goal is to improve the reach of the software but from observation I worry that it’s creating some challenges because you are catering to multiple environments.

In the recent past, I had decided to give up on packaging for newer versions of debian/ubuntu (they already have these tools though moving at a much slower pace because of packaging policies and such). But that decision ended up blocking our upstream CI testing for ubuntu 20.10. So, I had to re-enable packaging for 20.10 and I thought might as well provide these packages to the community while I’m at it. Of course, these are not official distro packages, and I’m not an official debian/ubuntu packager.

Effective bug resolution often works a bit like CPU cache locality – if you keep the bugs, expertise and code all in the same virtual location then you benefit from focused attention and reduced ‘fetch latency’ - not just from the team working on the software but also from contributors who arrive in the codebase/bug tracker/community. It’s just my two cents, but I think that Debian package bugs should exist in/near the repository that holds the Debian packaging code, etc.

Well, the debian packaging code that’s provided on the Kubic project is not the same as used by the official debian/ubuntu packages. The Kubic project’s debian code is present on https://gitlab.com/rhcontainerbot/podman/-/tree/debian (for podman example) which nobody usually cares about except me (well not even me, but rather my bot). And, I’d rather not upstream this code because I’m certain debian project wouldn’t like it or use it because I break a lot of debian’s rules (main one being building with bundled go libraries).

So, if you say “debian packaging bugs” wrt. Kubic, I guess github.com/containers is still the best place to file those, but if I come across bugs related to the official distro packages, I ask them to file at the distro’s bug tracker instead.

I guess I could have a kubic branch or something hosted upstream, but then again every time I bump this branch to a new version, it’s a force push (because of a rebase on the latest upstream release tag), and I don’t know if upstream or anyone that tracks this branch would like that behaviour.

Currently there’s a risk we all get frustrated and begin to back away from packaging if none of us can effectively solve problems relating to it. Pressure will rise if CRI-O and libcontainers become more popular, and I think they are well placed to.

The ideal solution IMHO, would be to have volunteers with debian packaging experience help out the official debian and ubuntu package maintainer ( @siretart) so that updates are pushed out faster and we don’t even need to have Kubic packages anymore.

One idea that springs to mind is that it could be worth engaging the teams from CentOS, Debian, etc and asking whether they would be willing to accept ‘donations’ of the existing packaging code as-is or with minor modifications – after review and/or if they meet their requirements. Perhaps that’s already been attempted, I’m sure there’s plenty of context I’m missing.

Well, RE: latest-and-greatest packages on CentOS, I’m the CentOS guy as well. I used to use CentOS’ community build systems earlier but I found OBS/Kubic to be an easier experience as well as a single place to host multiple distros. CentOS packages via Kubic just end up re-building the latest fedora release rpm sources, so that’s usually not much trouble maintenance-wise.

The official debian packaging code also exists independently on https://salsa.debian.org but I won’t be able to use it for the Kubic project.

A related question is ‘who pays for the builds’ - this could help determine who has the incentives to own the packaging repository, versioning structure, and tasks for each distribution.

Personally, I want to keep the community and upstream happy, and upstream CI as well as much of the community want latest-and-greatest that many distros often can’t provide because of various reasons/policies, so I do what I gotta do.

That said, if people in the community are willing to own the Kubic project packages and have them tracked on the Kubic project’s tracker, I’m willing to share access. So, let me know …

HTH and hope I didn’t misread anything.