comment #1:

> By "download" software from Debian, you mean the source tarballs, right? In particular, the "pristine-tar" branch of each package (like this one for Gnuastro. You don't mean downloading the binary packaged files, right?

I mean the source tarballs (pristine-tar) plus (at least) the debian patches, e.g. https://salsa.debian.org/science-team/gnuplot/-/tree/master/debian/patches or https://salsa.debian.org/debian-astro-team/inhomog/-/tree/master/debian/patches or https://salsa.debian.org/debian-astro-team/cfitsio/-/tree/master/debian/patches .

It's the patches that represent a major part of the Debian quality assurance pipeline in terms of fixing source code.

I definitely don't mean downloading the binaries - the Debian build system is only run on 22 different systems currently (9 official, 13 unofficial).

There may be other steps in the build process - checking parameters in debian/control , for example, that we might also want to implement. The debian/rules file often gives security hardening steps for compilation. The question for each step would be: is the advantage in reliability/security worth the cost in needing more tools?

Applying the patches - in the recommended order!!! - would already, it seems to me, implement a significant part of the benefit of Debian.

> If so, then your suggestion would translate to an interesting suggestion: only updating versions of software that are in certain stages of the Debian release (stable, testing or unstable). We can even write a small script to parse the unified Debian interface and get the list of packages that need updating.

Yes, that's definitely a good idea!

> Running this script can even be provided at configure time, so the person running Maneage can say that for example, I want all my software versions (with build instructions in Maneage!) to match the current Debian stable. That script would then update the project's 'versions.conf' and 'checksums.conf' source files and build those versions. Later, the user can commit the changes made in these files to be able to reproduce their project's software environment independent of future updates to the Debian stable, testing or unstable branches.

Would we want to add "our" archival copies of e.g. the debian stable packages in Zenodo/maneage? Or how long-term are the debian archives of orig tarballs and patch lists?

I guess by "commit the changes", you mean to archive them in Zenodo/maneage? My guess is that's probably reasonable. We could either choose to archive the patched files as a "patched archive" - for simplicity - or in the original debian format - for easier checking against the official debian versions.

> This would also greatly simplify the task of us Maneage maintainers (every month, we would just have to check with Debian testing and update the packages to versions that are now used there! Instead of manually going and changing all the versions like what I did the other day!

In terms of software security and reliability, this would seem a big improvement to me. I know you have good software skills :), but it's hard to believe that you really thoroughly checked all the updates to 20-30 or however many packages you updated.

Thanks for the interesting suggestion Boud.

By "download" software from Debian, you mean the source tarballs, right? In particular, the "pristine-tar" branch of each package (like this one for Gnuastro. You don't mean downloading the binary packaged files, right?

If so, then your suggestion would translate to an interesting suggestion: only updating versions of software that are in certain stages of the Debian release (stable, testing or unstable). We can even write a small script to parse the unified Debian interface and get the list of packages that need updating.

Running this script can even be provided at configure time, so the person running Maneage can say that for example, I want all my software versions (with build instructions in Maneage!) to match the current Debian stable. That script would then update the project's 'versions.conf' and 'checksums.conf' source files and build those versions. Later, the user can commit the changes made in these files to be able to reproduce their project's software environment independent of future updates to the Debian stable, testing or unstable branches.

This would also greatly simplify the task of us Maneage maintaiers (every month, we would just have to check with Debian testing and update the packages to versions that are now used there! Instead of manually going and changing all the versions like what I did the other day!