As far as detecting the DLC, it should (hopefully) be as simple as detecting the presence or lack thereof of specific files in the installation directory. This should piggyback off the existing autodetect mechanism and create a virtual package named MakingHistoryDLC that other mods can depends (or even conflicts) on. It could be a soft-convention that any official DLC have the suffix "DLC". This should make any dependency errors obvious to users attempting to install mods that require DLC they don't have. "Mod Foo requires MakingHistoryDLC which is not available in the repository." (or whatever the exact error message is).

We should also consider DLC versioning. Will updates to the DLC always be tied to a new KSP release (and therefore could share versioning) or would it have to be versioned separately...

I'm not sure whether we should handle missions made with the Making History DLC. Do they fall into our remit? We definitely need to detect and flag the DLC for conflicts and depends, though.

If modders start making custom missions I guess the users will expect us to start indexing said missions.

Making History's release date has been announced: March 13th, 2018.

CKAN has just over a month to get ready.

Ok, so do we handle Making History purely as an Autodetected mod, tagged as DLC (Pro: Minimal code changes required), or do we write some special DLC detection code to inject the prereq?

...or do we write some special DLC detection code to inject the prereq?

How would that differ from reusing the autodetect mechanism?

I took a look at this briefly to see what would have to be done. It seems relatively straightforward with one annoyance: the test for if something is an autodetected mod is if its version is of type DllVersion. I find this a bit awkward, rather than having an explicit Autodetected property or something, but it's workable. The big issue is that DllVersion right now doesn't actually store a version, which is problematic if we need to version the DLC separately (which I think is a good idea regardless). That's probably easy to rectify, however, without too much issue.

In summary these are the minimum changes I believe are necessary for support:

1. Modify DllVersion to take a version string parameter and pass it to the base Version class.
2. Modify DllVersion so that its ToString() method returns the actual version string rather than "autodetected dll", possibly with a (AD) tag or something. Although I think something like (Unmanaged) is more explicit about the relationship CKAN has with it.
3. Modify the KSP.ScanGameData() directory to include whatever check is necessary to detect that Making History is installed and hopefully extra a useful version or build number.

Bonus

1. Modify ScanGameData() to ignore specific dlls like KSPSteamCtrlr and Steamworks

I should have some time to do this if this is what we want to do and nobody else has a burning desire to.

Huge +1 on changing our "Autodetected" DllVersion to an "Unmanaged" marker that can track version numbers. Perhaps we could have a right-click menu option that will let users select the correct version number for an unmanaged object if we can't figure it out.

We could then add a tag to those Unmanaged objects for those that could in principle be brought back under CKAN management by a plugin.

Now that Making History is out it seems that detecting the DLC is just a matter of testing for the presence of GameData/SquadExpansion/MakingHistory directory. Also, it appears the DLC is versioned separately from KSP itself. The version can be extracted from the readme.txt file from the aforementioned directory; there doesn't appear to be any build ID for the DLC.

I'll update #2326 witht he appropriate code.