A possible PND-system replacement


DBP has the huge disadvantage to (at least currently) not working on exFat drives which is what large SD cards use.
DBP system didn't have this issue initially, seems to be an odd issue that cropped up shortly after official Pyra release and likely could be fixed with a little investigation. Also there are a half dozen other file system formats you can format SD cards to ext2/3/4 or even NTFS.
I do not really see the need for an appdata folder any more.
For ROMS and files, they should not be in specific appdata folders anyways but on universal places where different emulators can access them.
I used ROMs as a quick example, but for me real use cases would be something game engine ports were you have to place the original game data and mods in like quake, half-life... etc these are easily handled by overlay mounted appdata directories.
 
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:
  1. Check if exists a local file with the list (maybe in the same folder and with the same name of the DBP)
  2. ONLY IF not found locally, it will download it from the REPO, and put it in the same folder of the DBP
  3. 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)
  4. 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
  5. (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 =
 
Last edited:
It is great that you talk about this problem, because it is clearly a problem that needs to be addressed somehow.
The OS version doesn't change all the time. But it will change again I guess, bookworm is probably not the last version. With each new version, some of the .dbp files will not work anymore out of the box.

I think for the standard case (e.g. a .dbp build for bookworm is executed on bookworm) it's fine to have the list of dependencies inside the .dbp .

But the .dbp can become outdated, e.g. it was never build for bookworm but only for buster. For that case I like your idea of separation, but the separation should be optional in my opinion.
So to execute on bookworm a version of PGen-6.06.0.03.dbp that was build for buster, you could offer a separat "compatibility fix" file that overrides the dependencies and does the mapping.

The alternative would be to have our repo devided into the different OS versions. Each .dbp would contain information about the supported OS versions. If you wanted to have PGen for bookworm someone would need to create an updated .dbp
Maybe a mix of both solutions: We could try to write a helper tool, that makes repackaging of .dbp files for new OS versions less work.
 
Back
Top