Preliminary implementation of NetKAN files for RPM.

[KevinCathcart]

@Mihara,

I'm currently working on providing support for installing RasterPropMonitor via the Comprehensive Kerbal Archive Network (CKAN), which aims to provide mod management in a scalable and highly repeatable manner. If you've ever used apt-get under Debian or Ubuntu, it has many of the same principles (and is based heavily upon the Debian Policy Manual). CKAN is currently still in the build stage, and the developers aren't promoting it until they are sure that things are reasonably solid. In a nutshell, users can do things like ckan update, ckan install MechJeb2, (or use the GUI to perform the same tasks) and they'll automatically get the latest release, and dependencies, and it will make sure it works with their version of KSP.

Arguably the most important design consideration of CKAN to to impose as little overhead on mod authors as possible. This means that all required metadata is stored in external files managed by contributors to CKAN. That means that mod authors usually need to do absolutely nothing to be supported by CKAN, as long as some contributor cares enough to package their mod. Furthermore the NetKAN system exists which can scan supported sites (currently GitHub and KerbalStuff, hopefully eventually CurseForge too) to find new versions and automatically create updated metadata files, meaning that in most cases even NetKan contributors do not need to do anything to support new mod releases.

(The first half of the above sales pitch shamelessly based on one by @pjf).

Therefore, I'm mentioning you on this pull request to give you the opportunity to comment on the proposed packaging, or to object to your mod being packaged at all.

---

This pull requests adds a series of NetKAN files for supporting RasterPropMonitor.

There are three packages here. One is named RasterPropMonitor-Core which contains the core dll. Most other mods that depend on RasterPropMonitor should depend on this.

Then we have RasterPropMonitor-Library; This contains a library of example props that are used by raster prop monitor. There are some mods that require these, so a seperate package is needed for them. They obviously depend on RasterPropMonitor-Core.

Last but not least we have RasterPropMonitor, which contains the ModuleManager patches for adding enhanced IVAs to the stock crafts, and also the JSI agency and flag files. It is expected that no other mod will depend on this package, but some might suggest or even recommend it. Obviously this one depends on both other packages.

These changes are submitted under the CC-0 license, as per the NetKan requirements.

[Mihara]

I find that splitting plugin and library into separate packages is kind of unwise, for the simple reason that when people say "install RPM" they never say "you also require (or don't) the Library files". Certain components of RPM (the navball for example) use Library files as defaults. As a result, a particular IVA developer may not even be aware that the Library is required. Stock patch collection is quite independent, Library, not so much.

But if you can enforce that dependencies are always correct, feel free. :)

Oh, and one more thing: Unless there's a global preference to point to the forum threads, set the homepage to the Github releases page rather than the forum thread, please. Github is the primary authoritative source for RPM.

[KevinCathcart]

@Mihara
The UI already has a link to the github repository that is based on the repsoitory name in the CKAN file. Thus normally the homepage is specified to be the forum thread, just because it is king of strange to have two consecutive links with different labels pointing to the same url. The homepage link is optional though, so I can just drop it, leaving only the repository link.

As for a split core and library, the main reason I did that was based on the your distribution notes. Any mod that distributes just the dll per those instructions would be packaged to reference the core portion only. Most other mods would tell users to install RPM directly, in which case depending on the library package and suggesting the full package would be appropriate. But combining the core and library packages into one would be simpler if you think that is a more sensible way to go. It would avoid other packagers being confused.

Also should the third-party folder be merged into that package? That would result in that package installing the JSI/RasterPropMonitor folder as-is, and the main RasterPropMonitor package installing the Agency and RPMPodPatches folders. That is certainly simpler.

I've updated the pull request as mentioned.

[Mihara]

Well, I think that's better. :)

[pjf]

Just a quick note to say that these are looking really good!

I'm just waiting for KSP-CKAN/CKAN#269 KSP-CKAN/CKAN#309 to land before merging properly, as it allows us to do the right thing with the embedded .version file. :)

[pjf]

And we're good! Give our indexer a couple of minutes, and you should see both RasterPropMonitor and RasterPropMonitor-Core on the CKAN! You both totally rock.