Linux Developer Question (packaging)

[fizzyade 132]

I figured I may as well ask here as there's more than a few developers here....

I've been working on a project for a year (https://www.pingnoo.com or https://github.com/nedrysoft/pingnoo) and I've now completed a lot of a backend stuff in the application and am now moving onto features again.  I developed a script (deploy.py) which I use to create deployable images of the software for macOS, Windows and Linux.  Another developer has kindly done a lot of refactoring on it and it's now capable of generating fedora packages, deb packages and an AppImage.

As the app requires raw socket access (well, that was true, you do have the option to use the ping command to generate the ICMP requests, but the timing is not as accurate) you have to launch the AppImage as root, not ideal.  The extra deb & rpm packages solve this by installing the application with setcap priviliges for raw sockets.

All good so far.

Now, the fedora packages include the fedora version in the filename.  All good, you know which to download.

It's ubuntu/debian that's giving me nightmares, at the moment I don't have an Apt repo, I've applied for one for the project as it's OSS, but I won't hear back until next week.  Given that the packages aren't compatible between distributions or releases of the same distribution, how is the best way to name the packages.  Everywhere I've looked and every project I've looked at that has releases on github doesn't include this information on the deb file, so you have no idea which distro or release it's for.

Maybe I've misunderstood something and having an apt repo would solve the issue, but I can't seem to find any good answers on how you're supposed to know what distro/release a deb package is for unless it's put in the filename, and that doesn't seem to be a "done thing".

Can anybody give me some sort of clarity on this?

[Luke 42077]

@alucryd may have some insight on this.

[fizzyade 132]

29 minutes ago, Luke said:

@alucryd may have some insight on this.

Cheers.  I managed to find some kde packages that do add in the ubuntu version, so I've followed them for the moment.  It seems a bit of a mess, I'm not sure why their official naming doesn't mandate this.

pingnoo-2021.03.21-develop-ubuntu20.10_amd64.deb

<app name}-<version>-<branch>-<os+release>_<arch>.deb

I switched all my versioning to YYYY-MM-DD-<branch> about few years ago as I was tired of deciding when major/minor versions should bump.

 

[fizzyade 132]

Just a slight follow up incase anybody ever finds this thread via google or something....

As above, I settled on adding the os+version in the filename, it seems that KDE use that convention, but bizarrely it's not mandated by anybody - which seems really odd considering it's somewhat important.

I now have TeamCity building the following packages.

 

Windows x86_64 installer.

Windows x86_64 portable zip.

Fedora r33 rpm

Fedora r32 rpm

Ubuntu 20.10 deb

Ubuntu 20.04 deb

Ubuntu 18.04 deb

AppImage

Debian 10 deb

 

I would love to create a debian 9 package, but the version of Qt that is bundled with it doesn't support :: nested namespaces with the moc tool, so it fails to compile.  I made a few changes to get Ubuntu 18.04 working because certain Qt API calls I made are not in the version of Qt that ships with 18.04, if it wasn't for the moc issue I suspect it would probably be very close to (if not already) compiling on 9, but the only way really to fix the moc issue would be to de-modernize the code and remove nested workspaces using ::, which I'm not going to do because it makes for a lot cleaner code.

My NUC which runs proxmox and has a VM for opnsense as my gateway, has a load of teamcity build agent containers set up on it, my windows build agent runs in a virtual machine on my unraid server and the mac build agent runs on a mac mini.  The VM for windows also doubles as my windows dev environment and it's also where my code signing cert is, it's a smartcard based one which means it's not accessible via RDP, if you are logged in via RDP then code signing will fail, but because it's a unraid VM, it has KVM over VNC, so I just have to ensure that the last login was done via that.

I currently have 9 build agents set up, all of the linux ones are lxc containers running on proxmox.

The NUC has 64GB of RAM and I allocate 4GB of RAM to each container, 2GB RAM results in compilation failure as the compiler dies from lack of memory, I guess I should probably try 3GB...then I'd also free up some space for other containers!

Edited March 21, 2021 by fizzyade