@Andreas, how can I switch the default state of a package.
It's no problem to give examples. (NEPMD, my project, is one.) But from what you wrote after that, it seems that you rather need other support for that.
Honestly, 15 years ago, when starting porting and maintaining DOSBOX, somebody write me the Warpin scripts.
I don't remember how Dosbox is distributed. My first thought today: If I'll find time I'll enhance the WarpIN installation. Bur after having read what I wrote last night and what others wrote about system DLLs, my opinion has changed a bit:
In NEPMD, I've included 1) md5.exe by Bob Eager, 2) lxlite.exe and unlock.exe and 3) wptools.dll. These are must-have tools to allow NEPMD process basic functions.
To 1) md5sum is nowadays installed on modern systems. md5.exe is then deactivated on installation. But unfortunately an already installed md5.exe NEPMD tool is not automatically uninstalled if md5sum.exe was found in the meantime. Md5.exe itself hasn't changed in the past and because it's an EXE and not a DLL, it won't interfere with other apps. Therefore: No problem to provide md5.exe with NEPMD. I've left it in the NEPMD package, because it was included already before the RPM/YUM times. The same applies to both other tools.
To 2) lxlite.exe and unlock.exe are system tools since an eCS version. They haven't changed much in the past. bww has released a new version with included changes from various people. I had replaced the previous Hobbes files with the bww files in the NEPMD package. Again, these files are EXEs, so it's no problem for other apps. There were installed in a tools dir that is not included in NEPMD's extended PATH. That means that also from command line, ther's no danger with these files.
To 3) wptools.dll is included since an eCS version. Even being a DLL, distributing it maybe additionally with a package may cause no problems, because development has stopped and it hasn't changed since ages.
But I won't include any of the e.g. gcc* DLLs with NEPMD, because such files are maintained and changed often.
So in your case, I find it the best method to avoid inclusion of these files. That applies also to libcn. If you want to support people who defer to use RPM/YUM, I see it as the only option to provide the required files in a separate package. (Steve Wendt did that for Mozilla versions.) With "package" I mean also "file". That means: create a special .wpi with these DLLs, but better keep them quite hidden to ensure people don't install them by mistake.
Dave has already described what the biggest problem for other apps may be. So, easiest is to just refer to the "yum install" command to install the prerequisites. What WarpIN can do, is to check for prerequisites and defer installation without it. Let's see, if I find time during the weekend to give examples and to add that to the Dosbox .wis script.
