I'm sorry in advance if I'll say something already discussed, I still didn't read the entire thread and I'm not documented enough about DBP system.
From my experience between two OS versions I had issues with dependencies with almost all the DBP I tried in both of them, and I had to do manual corrections and manual package installation each time to make them work.
I see that there's already an implementation for checking and installing the required packages and that could be very useful, but right now it has different problems that are making it not so useful.
The main issue I found is that the dependency list inside a DBP could reference to a package that will change name in a different version of the OS, so this is what happens right now:
- A DBP checks if the package "pkg1" is installed in the system, but there is no "pkg1" in the repo, because the new version has the required libraries in a new "pkg2" package
- Let's say that the new libraries are still compatible with the old ones required by the DBP, so installing by hand "pkg2" we can get the new ones
- More manual work is required anyway, we need to create symlinks from the new libs with the names of the old libs, so the program in the DBP can find them during the run
- If the previous action made the DBP run, there is still a check at every launch about the missing "pkg1", even if now it is not required anymore
So, I think that this dependency list check should be separated from the DBP, and also should contain package names for different versions of the OS.
Could be possible to list the needed libraries of a DBP just from a file on the REPO, with entries separated by OS version ?
This way if a DBP could run in different versions of the OS, but with just different packages, there is no need for the developers to remake it just to change the checked packages, they just need to ADD the package names of the new OS version in the external text file.
Example:
a DBP by default has no list of libraries to check, but at the launch it will do this:
- Check if exists a local file with the list (maybe in the same folder and with the same name of the DBP)
- ONLY IF not found locally, it will download it from the REPO, and put it in the same folder of the DBP
- Get from the file the list of required packages relative to the current version of the OS (it could also contain a FLAG to make a particular OS version "UNSUPPORTED" or "NOT WORKING", disabling the dependency checks at the start and substituting them with the relative error message)
- Then it can start the normal dependency checks that it is already doing now, asking installation of missing packages, but that will have the right names for the current OS
- (For backward compatibility with older DBPs) If no external file was found both locally or online AND the DBP still contains a dependency list, this will be used like now, else the external file should have the priority over the internal list.
This way it is also possible to stop warning messages of not found packages just by creating an empty list file in the same folder for the older DBPs.
Now, there could be another upgrade to the "external file list" system, a list of required commands to make the DBP fully working without manual intervention... because with the previous solution the package installation is fixed, but not the correction of library files that have different names between OS versions.
Example on the SAME DBP in different versions of the OS:
- on Buster there's a library called "lib1.1.so", but the program in the DBP require the "lib1.0.so", the "command" in the file could be "[SYMLINK] [lib1.1.so] [lib1.0.so]"
and locally will be launched "sudo ln -s /usr/lib/arm-linux-gnueabihf/lib1.1.so /usr/lib/arm-linux-gnueabihf/lib1.0.so" (maybe with a check if the old library was already present)
- on Bookworm there's a library called "lib2.0.so", but the program in the DBP require the "lib1.0.so", the "command" in the file could be "[SYMLINK] [lib2.0.so] [lib1.0.so]"
and locally will be launched "sudo ln -s /usr/lib/arm-linux-gnueabihf/lib2.0.so /usr/lib/arm-linux-gnueabihf/lib1.0.so" (maybe with a check if the old library was already present)
I'm not a security expert, but the "command system" should be very limited with just parameters, the file should not contain full scripts that can be run on the system, only the necessary values that will be used by internal functions of the DBP system.
Maybe even the library path could be hardcoded inside the DBP system function, or maybe taken from a local file or environment variable.
With this solution there's only a single file to be updated on the repo if something changes between OS versions, and the DBP can stay (in the majority of the cases) the same.
EDIT:
An example of a potential dependency list file:
Code:
[Debian < 11]
Flag = OK
Dependency = pkg1, pkg2
Commands =
[Debian 11]
Flag = OK
Dependency = pkg1, pkg2, pkg3
Commands = [SYMLINK] [lib1.1.so] [lib1.0.so]
[Debian 12]
Flag = OK
Dependency = pkgone, pkg2-4, pkg3_1
Commands = [SYMLINK] [lib2.0.so] [lib1.0.so], [SYMLINK] [libother1.3.so] [libother1.2.so]
[Debian > 12]
Flag = "NOT WORKING"
Dependency =
Commands =