Standalone packages for libraries(.dll)?

[bharatvaj]

I wanted to create a package for roff but the binaries depend on several dlls. I glanced through the Main bucket and couldn't find any standalone dll packages.

I guess it won't be possible to maintain dlls for every package, but is it possible to support for important ones, such as readline, iconv, zlib, etc?

[niheaven]

Please see https://github.com/ScoopInstaller/Main/blob/master/bucket/tar.json for reference.

[bharatvaj]

Hey thanks for the reply. The link you sent implies the solution that involves adding the .dlls directly to folder of the binary file. Me on the other hand trying to start a conversation regarding standalone .dlls in scoop. That way we can share the dlls between multiple packages using the "depends" keyword in the manifest file.

Current

        "url": {
        "https://downloads.sourceforge.net/project/mingw/MSYS/Base/libiconv/libiconv-1.14-1/libiconv-1.14-1-msys-1.0.17-dll-2.tar.lzma",
        "https://downloads.sourceforge.net/project/mingw/MSYS/Base/gettext/gettext-0.18.1.1-1/libintl-0.18.1.1-1-msys-1.0.17-dll-8.tar.lzma",
        "https://downloads.sourceforge.net/project/mingw/MSYS/Base/regex/regex-1.20090805-2/libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma"
        }

What I'm proposing

     "depends": [
          "libiconv-1.14",
          "gettext-0.18.1",
          "libregex-1.20090805"
       ]

Hopefully creating the manifests for libraries in separate bucket called "Lib"

[HUMORCE]

depend: lib
post_script: creating symlinks or copying for lib's files

notes:

• Symlinks creating requires admin privileges or enabled developer mode.
• Symlinks does not work for some program, you should complete copied the lib files to correct path.
• Consider about differences between Windows and nix.

[bharatvaj]

After some preliminary testing, I would suggest using "hard links" instead of symlinks,
(sorry for taking 3 months to reply :{})

• Hardlinks does not require admin privileges. This article only prohibits hardlinks between drives.
• Hardlinked dll seems to work for preconv in gnu troff by linking libiconv2.dll in the same folder, but I can do more testing if I'm nudged in the direction of what use cases fail.
• Hardlinked dlls have superior advantage that symlink lacks. The file in question gets deleted only when the last reference to the file gets deleted. This means that when a user deletes the libiconv package for some reason or the other, we can leave out unlinking libiconv2.dll in dependent programs like troff. Ensuring that troff will work, even after deleting the dependency. Sometimes this is useful when doing updates to core packages - if there are any, or in the future. *NIX way or windows way, I(and I assume others) would prefer updating only one package instead of all the dependent packages.

post_script: creating symlinks or copying for lib's files

I would suggest copying all .dlls as hardlinks to the dependent's location when regarded as dependency, unless overridden in the json file.