I recommend increasing NSIS_MAX_STRLEN to 8192 at compile time. Patch attached. Using NSIS_MAX_STRLEN=8192 seems to be a common desire, since there are dedicated upstream builds with that option: https://nsis.sourceforge.io/Special_Builds So far we recompiled nsis with that large strings option, mainly to mitigate actually a serious problem with nsis: it is common procedure for an installer to append a string to the system's PATH variable, e.g.: ${EnvVarUpdate} $0 "PATH" "A" "HKLM" "$INSTDIR" If however the PATH variable on the system is already very large (i.e. if the string in the current PATH variable exceeds the default nsis string length of 1024), then nsis no longer appends to PATH; it then simply overwrites PATH (i.e. with $INSTDIR in this example), so all other directories previously contained in PATH are gone! I must admit, I haven't checked whether this serious bug had already been fixed upstream. However increasing max. string size is still a good idea to prevent string manipulation issues in general.
The discussion within bug report #432713 (https://bugs.debian.org/432713) is relevant here as well. Nevertheless I think it might be worthwhile providing the stubs of the special builds of "advanced logging" and "large strings" via an optional Debian package. Unfortunately it is not sufficient to only provide the stubs of the special builds. The makensis executable is not generic enough to cope with the default and special builds. So for each build the stubs and the respective makensis compiler is required. My preference would be to have just one generic makensis compiler dynamically supporting the default and special builds.
Ok, I see the point about generated stubs. But generating linear combinations of nsis compile time options as their own packages, like nsis nsis-common nsis-log nsis-common-log nsis-8kstr nsis-common-8kstr nsis-log8kstr nsis-common-log8kstr wouldn't that be a bit too exorbitant for the purpose? As far as I can see it, the argument about logging not recommended to be activated by default was a size difference of generated installers being in single digit kB range. And about NSIS_MAX_STRLEN=1024 vs. NSIS_MAX_STRLEN=8192 it seems to be a similar argument, which I guess is slightly reduced RAM usage peaks when executing the generated installer. As long as I am not missing anything here, I would just enable both options by default instead of all the burden of maintaining separate packages for all considerable options.
I just imagined to have one additional package. Let's call it nsis-special for the sake of simplicity. nsis-special would have the following content: /usr/share/nsis/Special/8kStrings/bzip2_solid-x86-ansi /usr/share/nsis/Special/8kStrings/bzip2_solid-x86-unicode /usr/share/nsis/Special/8kStrings/bzip2-x86-ansi /usr/share/nsis/Special/8kStrings/bzip2-x86-unicode /usr/share/nsis/Special/8kStrings/lzma_solid-x86-ansi /usr/share/nsis/Special/8kStrings/lzma_solid-x86-unicode /usr/share/nsis/Special/8kStrings/lzma-x86-ansi /usr/share/nsis/Special/8kStrings/lzma-x86-unicode /usr/share/nsis/Special/8kStrings/uninst /usr/share/nsis/Special/8kStrings/zlib_solid-x86-ansi /usr/share/nsis/Special/8kStrings/zlib_solid-x86-unicode /usr/share/nsis/Special/8kStrings/zlib-x86-ansi /usr/share/nsis/Special/8kStrings/zlib-x86-unicode /usr/share/nsis/Special/Logging/bzip2_solid-x86-ansi /usr/share/nsis/Special/Logging/bzip2_solid-x86-unicode /usr/share/nsis/Special/Logging/bzip2-x86-ansi /usr/share/nsis/Special/Logging/bzip2-x86-unicode /usr/share/nsis/Special/Logging/lzma_solid-x86-ansi /usr/share/nsis/Special/Logging/lzma_solid-x86-unicode /usr/share/nsis/Special/Logging/lzma-x86-ansi /usr/share/nsis/Special/Logging/lzma-x86-unicode /usr/share/nsis/Special/Logging/uninst /usr/share/nsis/Special/Logging/zlib_solid-x86-ansi /usr/share/nsis/Special/Logging/zlib_solid-x86-unicode /usr/share/nsis/Special/Logging/zlib-x86-ansi /usr/share/nsis/Special/Logging/zlib-x86-unicode plus some documentation what it is and how to use it. This package provides the stubs of the special builds (namely "Advanced logging" and "Large strings") as described on the NSIS Special Build web page (https://nsis.sourceforge.io/Special_Builds). I would prefer to be consistent with upstream. Therefore I am hesitant adding more stubs (e. g. combination advanced logging and large strings) to the nsis-special package. More details how I intend to proceed are available at: https://sourceforge.net/p/nsis/feature-requests/552/ Please provide your feedback. I might have overlooked some things that are important to you.
Well, if you prefer to handle that as one new separate package, that's fine with me of course. Personally I would favour severe/security concerns (e.g. the mentioned potential PATH variable corruption) over soft issues (e.g. installer size / upstream consistency), and hence would always enable long strings, but that's just my opinion.
Looking at your suggested diff: https://sourceforge.net/p/nsis/feature-requests/552/ If you really to decide to go that route with separate package: how about adding an extra branch in Source/build.cpp: If environment variable NSISSTUBSDIR was not set at all, then check for existence of the "special" stubs directory and if it exists, prefer that (existing) special stubs dir over the standard stubs dir? I mean if someone installed the special stubs package, then that user probably wants to use that, right? If not then the environment variable can still be used of course to override back to standard. So something like that (pseudo code & pseudo diff):--- Source/build.cpp (revision 7127) +++ Source/build.cpp (working copy) @@ -407,8 +407,13 @@ includes_dir += PLATFORM_PATH_SEPARATOR_STR _T("Include"); include_dirs.add(includes_dir.c_str(),0); - stubs_dir = nsis_dir; - stubs_dir += PLATFORM_PATH_SEPARATOR_STR _T("Stubs"); + dir = _tgetenv(_T("NSISSTUBSDIR")); + if (dir) { + stubs_dir = dir; + } else { + const char* special_dir = nsis_dir PLATFORM_PATH_SEPARATOR_STR "special"; + DIR* special_dir_ent = opendir(special_dir); + if (special_dir_ent) { + stubs_dir = special_dir; + closedir(special_dir_ent); + } else { + stubs_dir = nsis_dir; + } + stubs_dir += PLATFORM_PATH_SEPARATOR_STR _T("Stubs"); + } if (set_compressor(_T("zlib"), false) != PS_OK || set_target_architecture_data() != PS_OK) {