bmw

That is obvious by association, but it doesn't seem obvious to me from the context provided on that page that the grant of permission is needed (and it's not really explained anywhere I could find in the CKAN docs). For me, being more familiar with the open source software world where asking the authors permission before packaging software for a Linux distribution is unheard of, having to grant permission, particularly for a mod which already has a permissive license explicitly allowing people to do what they want with the mod (under the conditions of the license) is not something I would expect. There are also some mods which CKAN doesn't really handle that well (and maybe I'm just a purist; from a practical perspective, CKAN generally works fine. I'm just pointing out that an advantage of Portmod is that it can relatively clearly and concisely combine various options into a single package rather than having to duplicate lots of data and split things across multiple packages. CKAN's method is certainly a good way of keeping the spec concise). E.g. AdvancedFlyByWire has separate packages for Windows/OSX/Linux, while Portmod could package that as a single combined package. The same is true for CKAN packaging variants of texture mods for each size separately, or different configuration files meant as compatibility for different mods, packaged separately from the main mod and with a package for each different alternative. Maybe one possibility for Portmod and CKAN coexisting is that CKAN could be used for the vast majority of mods that work well with it, and Portmod could be used alongside it for installing mods which are more complicated. I don't know if that's the best option, I'm just hypothesising. Portmod can install software as well as mods, and as long as it's possible to compile the mod from a script of some form, it should be possible to automate installing the compilers and libraries and compiling it with Portmod. Some patching may be required if mods expect libraries to be in unusual places. On Linux binary packages can be borrowed from a Linux distribution. Alpine Linux seems particularly well suited since it builds software against musl and has a lot of statically linked packages which would reduce the number of dependencies. On macOS it might be possible to leverage homebrew packages, or homebrew itself. On Windows it would probably be more difficult since Portmod's sandbox restricts writes to the registry, so unless the tools have portable versions, it may not be possible to install them using Portmod in its current incarnation. However I've looked at using Docker in the past (I didn't test on Windows but it worked fine on Linux), which should work in this situation, though it's somewhat more complicated to install than Sandboxie, the current sandboxing tool. I'm not sure what point you're trying to make here. I'm not trying to suggest that Portmod is universally superior to CKAN, or that it should replace CKAN entirely. It's a different piece of software with different advantages and disadvantages, and yes, it's CLI-only (personally, I prefer CLI package managers to GUI ones; I don't consider it a fatal flaw if that's what you're implying, though I admit that may mean some people may not be comfortable using it). I started working on it four years ago for OpenMW mods. Some small amounts of work have been done for a few other games, but never really advertised much or maintained. It's not particularly well-known, largely because I spend most of my time tinkering with software rather than advertising it online, though lately I've been trying a little more to do so. Adoption in the OpenMW community has been relatively slow but steady, however it is hindered by few contributors and a lack of consistency in mods, which makes packaging take more time and require a lot of manual checks (nexusmods being the most common distribution site for mods doesn't help).

What I've read mostly indicates that the objections to mods being indexed is a matter of things specific to CKAN, more than a general problem (e.g. stability, as mentioned, as well as for Principia it seemed to be because CKAN can't do anything about certain external dependencies). I'm not opposed to only adding mods with explicit permission, I was just asking about the background as the motivations and implementations are not very clear to me (e.g. the spacedock "Add to CKAN button" is presented just as a way to add it to CKAN, there's no mention that you have to give permission, and while I have run across the fact that CKAN only includes mods with explicit permission when reading CKAN issues, I don't see any official description of that policy in the README or FAQ). I'm not looking to fracture the community, just wondering if there is any interest in Portmod (maybe I didn't communicate that as well as I could have in the initial post). If so, it might be possible for them to coexist without issues. This isn't a zero-sum game; multiple package managers can each bring their own benefits to the community. Portmod could be used, for example, to compile mods from source. I don't know enough about the KSP modding architecture to know if there is an advantage to that for users, but if ABI changes occur without API changes, it could provide better compatibility (setting it up could be complicated though, particularly on Windows). Portmod also has a number of packaging features which CKAN lacks (last I checked anyway). E.g. to name a few: Support for multiple source archives in a single package file Support for tar.{gz,bz,xz} by default in addition to zip, and other archive formats by installing tools itself (e.g. the bin/7z package for openmw) Support for platform-specific installation behaviour Support for optional mod features (including full support in dependency resolution and fetching) More or less arbitrary installation scripts in case mods are more complicated (fortunately doesn't seem like that's usually an issue for KSP) But if there isn't any interest in directly using Portmod's packaging environment, I could just set it up as a CKAN-meta client like I did for KSP1, assuming there aren't any major objections to that, as it would at least keep the package metadata unified and shouldn't fracture anything.

I sort of understand what you mean, but Portmod's repositories are just metadata repositories. I'm not redistributing the mods (except sometimes when they have a license permitting it, but I haven't set up anything like that for ksp2), and all information about the mods points to the original homepages and documentation (i.e. I'm not doing anything that legally requires me to get the mod author's permission). I'm aware that CKAN has had some issues in the past with mod authors complaining about being overwhelmed by misdirected user complaints when CKAN metadata is incorrect (though I may be missing some of the details), is that the sort of thing you're referring to? Portmod takes a much more conservative approach to packaging (based on Gentoo's model for package stabilization). Generated packages, as mentioned, start as "untested", and the idea is that they get tested manually, marked as "testing", then stabilized after some time has passed and the stability has been independently verified (in practice however the distinction between testing/stable has been ignored, essentially making everything perpetually "testing", since there haven't been sufficient contributors to make the the extra stabilization stage beneficial). More experienced users (who in theory know better than to complain upstream) can set Portmod to "accept" testing packages and then report any issues they find to help with the stabilization process, while less experienced users who just want things to work will just get the stable packages by default.

I don't see any way of reading that data from the spacedock API. There's just a field when posting a new mod. Is this a permissions thing, or is it just a way to trigger the generation of a package? Taking a quick look at the spacedock code, (this being what I found) I don't think there's really an equivalent for portmod at the moment, both because there isn't a server to notify, and because while importmod can generate packages automatically, I'm not sure the package generation is quite ready to be completely unsupervised. I've done it in a limited capacity in the past (with the exception of the portmod/ckan repo for ksp1), but the general idea has been that generated packages are marked as untested and any stable package versions will be preferred over untested packages during dependency resolution. I noticed that one mod which I packaged includes a netkan file, which should be sufficient for completely automated package generation since it includes dependencies and installation data (lacks optional features I assume since CKAN also does, but so far I haven't seen any of those anyway). Some of the others at least have swinfo.json, which has dependencies, but not install paths, so importmod would have to rely on heuristics which can easily fail, particularly if stuff like a builtin mod loader changes how things install.

Edit: to clarify, as my intentions may not have been clear from the initial post, I'm mostly looking for feedback here and would like to know if there is any interest in using Portmod I've put together a KSP2 mod package repository to use with Portmod https://gitlab.com/portmod/ksp2 I haven't actually tested it properly as I don't have a copy of KSP2 yet, but it happened to be a great way to test some improvements I've been making to Portmod's package generator tool, mostly because ksp mods have direct downloads, standard licenses and very good metadata available, so I could quickly test several new mods without having to enter much manually, and without having to mess with nexusmods for other games (ksp stuff is a pleasure to work with by comparison). But in case anyone's interested, here it is. There aren't any KSP2-specific guides on the Portmod wiki yet, but you can in short: Install Portmod: https://portmod.readthedocs.io/en/stable/install/index.html Setup a prefix with portmod init <prefix_name> ksp2 <ksp_directory> (your choice of prefix name, Portmod stores configuration globally rather than being local to a particular directory like CKAN, so you use 'portmod <prefix_name>' to run commands for a given prefix) Start installing mods (See https://portmod.readthedocs.io/en/stable/basic-usage.html) As mentioned in the Portmod thread, there isn't great support for game engine versioning yet, but it's being worked on.

Portmod Homepage: https://gitlab.com/portmod/portmod Wiki: https://gitlab.com/portmod/portmod/-/wikis/KSP/KSP (KSP-specific info and guides, not much at the moment) Documentation: https://portmod.readthedocs.org/ (specific to the portmod tool itself) License: GPL-3 Portmod is a general-purpose package manager for Linux, macOS and Windows, targeting game mods. It's been under development since the beginning of 2019, primarily targeting OpenMW, but now also provides support for Kerbal Space Program using the metadata from CKAN-meta (and a conversion script). It's currently CLI-only, though work on a GUI is in-progress. Current State of KSP Support There are a couple of outstanding issues related to KSP support and the limitations of the CKAN conversion: Portmod doesn't support variable game engine versioning, so a rougher approach is taken instead and a game architecture is set up for each minor version. Patch versions are considered compatible with each other, which may not always be true. Proper support for game engine versions is in progress. CKAN's version format is more permissive than Portmod's. In practice this means that a handful of packages are omitted from the repository due to versions which cannot be parsed. It's also possible that some packages are ordered incorrectly due to the conversion being fairly rough. Benefits compared to CKAN Portmod primarily was created to target modding ecosystems which lack package managers entirely, however KSP's mature packaging ecosystem gave an opportunity for portmod to support a large number of packages which were created for a different system. Compared to CKAN, Portmod's primary benefits, aside from interface preferences, are in its highly extensible package format. Portmod's packages are Python scripts (sandboxed for security) and support just about whatever installation method is needed. Support for CKAN's package intallation, for example, is implemented through one such script and inherited by all packages converted from CKAN metadata. Note that despite being a source-based package manager, Portmod generally still handles binaries instead of compiling packages from source, to avoid having to package the entire build environment, though building packages from source should be possible. The package format also supports optional build features, based on Portage's USE flag system (with a few small modifications). This allows patches to handle conflicts with other packages, or alternative configurations, to be handled within a single package. Obviously, relying on CKAN-meta for packages means that package format features which CKAN lacks go unused, however they may be useful for supporting mods which can't be properly supported by CKAN, or if there is interest in setting up KSP packages specifically made for Portmod.