The Comprehensive Kerbal Archive Network (CKAN) Package Manager; v1.18.0 [19 June 2016]

[Olympic1]

Sorry, don't mean to interject in your guys', er, discussion... but can anyone confirm that kerbalstuff is experiencing downtime right now? It appears that my CKAN is getting 504's on any kerbalstuff downloads.

Does CKAN support multiple download locations? Like fallback repositories?

Having the same issue hear JordanL. I'm glad you said something I was about to tear my hair out thinking I somehow broke my CKAN install (I'm a linux noob' date=' I'm always breaking stuff).[/quote']

Yes, KerbalStuff is experiencing some problems with downloads.

[Sivuden]

CKAN is nice. It's useful, makes it easy to install and manage mods. I've also, as an end-user, run into the problems Ferram seems to be pointing out-- I was tweaking my modlist through CKAN over the past week, and was running into weird issues more and more. Finally checked here, saw the current discussion, and checked my installed mods. and they're screwed all to hell. Literally just installing/uninstalling and updating mods all through CKAN's interface. I have various mods that are simply outright missing files, not to mention CKAN's error handling seems atrocious, leading it to corrupt files when it crashes.

It was nice using CKAN, but until it's actually capable of doing what it says on the tin I'll be doing things manually again.

[politas]

But they don't. No one tests the metadata generated to see if it properly installs the mod before it's sent out for general use. And no one bothers to provide any out for what happens when CKAN does cause problems and won't fix it, besides suggesting that I clean up their problems for them.

Sorry, Ferram, that's just not true. And every time you make statements like that, denying the efforts of CKAN contributors, you make actual conversations to sort out the problem more difficult, because you annoy everyone who has made attempts to fix things in CKAN.

But mod incompatibilities are rare and can be seen coming a mile away... planet packs, MechJeb-like things, aero models, the only type of common incompatibility is when two things try to mess with the same system, and that takes about 5 seconds of thought to figure out. I don't see how CKAN is necessary for that.

I'm sure if it's as rampant as that, you can provide a bunch of examples of that, right? I mean, an epidemic of that that requires this kind of tool should result in a list of several dozen mods that don't fall under the, "it's obvious they're messing with the same system" rule, right?

(Sorry for re-ordering your paragraphs, but I'm responding to these two together.)

The most egregious example is the fact that many, many mods include their own distribution of ModuleManager.dll (including you), and some of them bury it somewhere in their own mod's directory. So you have to track down every copy of ModuleManager.dll that ends up in the system, hope that all the mods are happy with the newest version while you delete all the old ones and make sure there's only a single copy.

The particular mods that really drove me up the wall were the beautification mods. TextureReplacer, Active-Memory-Reduction, Distant Object Enhancements, Planet Shine, Ven's Stock Revamp, Environmental Visual Enhancements, CollisionFX, Reflection Plugin, Smokescreen, CoolRockets, HotRockets, RealPlume, etc. There are a bunch of dependencies and incompatibilities among these mods (and I'll even leave out the disastrous Renaissance Compilation here). Mods that include other mods as part of their distribution (or just one small part of that mod) are common. How many mods throw in a copy of Firespitter.dll? When a new version of the included mod is available, should you upgrade that, or wait until the mod that installed it includes the upgraded version? Add in to this that many mod authors completely ignore non-Windows users in their installation instructions. (You yourself keep talking about "winzip".)

God, please no. We'd all get forced onto Curse, have strict limits on what would be allowed, get the fun of bugs in that system getting fixed horribly slowly, have difficulty even identifying the bugs and not even have the option of pushing for manual installs. That would be utterly terrible. Even CKAN is better than that.

Well, could you keep that in mind?

[passinglurker]

The most egregious example is the fact that many, many mods include their own distribution of ModuleManager.dll (including you), and some of them bury it somewhere in their own mod's directory. So you have to track down every copy of ModuleManager.dll that ends up in the system, hope that all the mods are happy with the newest version while you delete all the old ones and make sure there's only a single copy.

The particular mods that really drove me up the wall were the beautification mods. TextureReplacer, Active-Memory-Reduction, Distant Object Enhancements, Planet Shine, Ven's Stock Revamp, Environmental Visual Enhancements, CollisionFX, Reflection Plugin, Smokescreen, CoolRockets, HotRockets, RealPlume, etc. There are a bunch of dependencies and incompatibilities among these mods (and I'll even leave out the disastrous Renaissance Compilation here). Mods that include other mods as part of their distribution (or just one small part of that mod) are common. How many mods throw in a copy of Firespitter.dll? When a new version of the included mod is available, should you upgrade that, or wait until the mod that installed it includes the upgraded version? Add in to this that many mod authors completely ignore non-Windows users in their installation instructions. (You yourself keep talking about "winzip".)

So ckan wants to be the only game in town by forcing mod devs to package their mods without dependencies there by making it harder on manual installation? Packageing dependencies is a good thing module manager is even writen to find all it's accidentally installed copies and pick the latest to run.

Still don't you find it funny that all the mods that might be a little tricky to install manually are the same mods ckan fails at? Makes you wonder whats the point doesn't it?

As for non windows user what kind of backwards Linux distro can't crack a zip file? What sort of Linux user can't drag and drop files?

[ferram4]

Sorry, Ferram, that's just not true. And every time you make statements like that, denying the efforts of CKAN contributors, you make actual conversations to sort out the problem more difficult, because you annoy everyone who has made attempts to fix things in CKAN.

So you're denying that the Netkan bot creates metadata files that are immediately pushed to the repo that CKAN uses without being tested by the maintainers at all? So then why did CKAN contributors allow broken metadata of FAR to be pushed out that didn't download dependencies, downloaded the wrong version of dependencies, and then didn't sort versions properly? You can feel bad that I'm denying your "lived experiences" of having tested metadata before it goes out, but I have evidence in the way of support requests in my thread to back up the fact that you guys don't bother to test metadata to see if it works.

This is another one of my problems with CKAN contributors. Faced with complaints about how they handle things, they immediately decide that their opponent must be lying. It only makes me think you're more out to screw me over, because I know damn well I had to put effort in to deal with your failure to test it. So did my users; wanna tell them that they were lying about their installs not working when trying to install FAR 0.15 through CKAN?

The most egregious example is the fact that many, many mods include their own distribution of ModuleManager.dll (including you), and some of them bury it somewhere in their own mod's directory. So you have to track down every copy of ModuleManager.dll that ends up in the system, hope that all the mods are happy with the newest version while you delete all the old ones and make sure there's only a single copy.

There is no such thing as ModuleManager.dll. There is ModuleManager.2.4.0.dll, and ModuleManager2.5.8.dll, and so on, all there to solve the problem that you're alleging happens. MM solved that problem a long time ago, and you're just betraying that you don't know how things work here. As passinglurker has said, MM already makes sure only the most recent version runs.

The particular mods that really drove me up the wall were the beautification mods. TextureReplacer, Active-Memory-Reduction, Distant Object Enhancements, Planet Shine, Ven's Stock Revamp, Environmental Visual Enhancements, CollisionFX, Reflection Plugin, Smokescreen, CoolRockets, HotRockets, RealPlume, etc.

...but most of these mods are as simple and dumb as nearly any other mod to install. I've done manual installations of TextureReplacer, ATM, Distant Object, VSR (without the pruning method), EVE, CollisionFX without any issues and without any conflicts. Then, Smokescreen isn't a stand-alone, it's a dependency for things like RealPlume. And RealPlume and HotRockets both fall under "seen it coming a mile away" because both mess with the same system: engine exhaust particles.

None of those alone have any reason to need CKAN, AFAICT.

There are a bunch of dependencies and incompatibilities among these mods (and I'll even leave out the disastrous Renaissance Compilation here). Mods that include other mods as part of their distribution (or just one small part of that mod) are common. How many mods throw in a copy of Firespitter.dll?

There are only three that I know of: Firespitter.dll and ModularFLightIntegrator.dll, which could be a problem, but are updated so infrequently that it only comes up in the mess of KSP updates (which CKAN has no hope to fix) and then KSPAPI, which, like MM, is deliberately designed to ensure the most recent version runs / the version that particular mod needs. Which is why it's bundled inside mod folders as it's supposed to be.

When a new version of the included mod is available, should you upgrade that, or wait until the mod that installed it includes the upgraded version? Add in to this that many mod authors completely ignore non-Windows users in their installation instructions. (You yourself keep talking about "winzip".)

If it uses a common version, you can always upgrade, because dependencies rarely break compatibility; the only time it has ever happened was when CKAN ended up distributing an in-development version of a dependency instead of the actual release version that it should have.

As for other OSes, thanks to the wonder that is coding in C# and JIT compilation, we don't need to care. Copying folders on Windows and Linux (so long as you're not forced to the terminal) is virtually identical, and only Mac OS has the weirdness of not-merge by default. Also, sorry that I don't know the name of a non-Windows winzip-like utility, I don't use them. I assume that my users are competent enough to know how to extract from a zip, which seems like a pretty low bar to meet.

Well, could you keep that in mind?

The fact that you're not the worst possible thing doesn't mean that you're good. That you cause less problems for me than that doesn't mean that I have to be happy about the problems that you cause.

[Ippo]

At the cost of repeating myself, I will once again let people know that I am absolutely in favour of removing FAR from CKAN's index as the author clearly doesn't want it to be there.

[ferram4]

I'd be quite happy to leave it there so long as I had the option to de-list it. If CKAN set for itself the goal of keeping things working perfectly, accepting the punishment of losing mods if they didn't, they'd be in a much better situation, and while I would still dislike CKAN and not understand the point, I would at least accept it and provide support for its users as I did before the shenanigans where they broke FAR installs completely. Currently though, they have no incentive to keep things functional, they have enough good PR among users to brush off any criticism, and they can calmly take advantage of the common user assumption that mods being on CKAN is opt-in, when it isn't even opt-out. And all of this shows in how CKAN works in practice.

[politas]

So you're denying that the Netkan bot creates metadata files that are immediately pushed to the repo that CKAN uses without being tested by the maintainers at all?

No, I don't deny that. But that is not what you said that I objected to. You said that when anything went wrong, the first thing the CKAN maintainers do is throw everything on the modders. The discussions I've seen on the NetKAN github do not support that conclusion. Asking a modder to change how they do things or help with the CKAN packaging comes very late in the process. If anything, the problems users are having with your mod through CKAN are probably at least partly due to CKAN contributors trying and failing to fix the metadata themselves without talking to you, while not understanding how your mod actually works.

So then why did CKAN contributors allow broken metadata of FAR to be pushed out that didn't download dependencies, downloaded the wrong version of dependencies, and then didn't sort versions properly? You can feel bad that I'm denying your "lived experiences" of having tested metadata before it goes out, but I have evidence in the way of support requests in my thread to back up the fact that you guys don't bother to test metadata to see if it works.

The assumption is that mods stay basically the same, with the same requirements. If the dependencies change radically, then yes, things will get screwed up. That is definitely a flaw in the CKAN model, but testing every metadata change is simply not a practical goal for CKAN maintainers. CKAN is tracking over a thousand mods, and there are only a handful of contributors. The initial metadata addition is tested, although the automated CKAN integration KerbalStuff implemented is somewhat of a hack job, and I'm not sure how thorough the testing of any submissions it puts in that get past the automated verification checks (which is not a lot). But again, you're talking about a different thing than what I said. I was responding to your assertion that CKAN contributors automatically refer any issues that crop up to the modders. I never said anything about testing metadata releases.

EDIT: Looking back, I realise that the paragraph I was replying to started out with a comment about testing metadata, so it may have seemed like that was the statement I was saying was not true. It wasn't. It was the final statement in the paragraph. My apologies for the confusion.

This is another one of my problems with CKAN contributors. Faced with complaints about how they handle things, they immediately decide that their opponent must be lying. It only makes me think you're more out to screw me over, because I know damn well I had to put effort in to deal with your failure to test it. So did my users; wanna tell them that they were lying about their installs not working when trying to install FAR 0.15 through CKAN?

I didn't say you were lying, I said that your claim was not true; that you were mistaken. I easily believe that users are having FAR installs not working through CKAN. I haven't managed to get a working FAR installation since KSP 1.0 came out, myself. My solution so far is to not use it in the hope that it'll get fixed eventually. I'm sorry that other people are hassling you about it rather than CKAN maintainers. If I cared more about FAR, I'd be trying to fix the metadata myself, or at the very least getting involved in whatever discussions are happening about it on the CKAN Github.

There is no such thing as ModuleManager.dll. There is ModuleManager.2.4.0.dll, and ModuleManager2.5.8.dll, and so on, all there to solve the problem that you're alleging happens. MM solved that problem a long time ago, and you're just betraying that you don't know how things work here. As passinglurker has said, MM already makes sure only the most recent version runs.

Maybe it's been fixed since I started using CKAN. I know that I ended up with two different versions of Module Manager trying to run simultaneously at one point, thanks to a mod that included a ModuleManager.*.*.dll in a subdirectory. That particular problem may well have been fixed by now. All my examples of what drove me to CKAN are out of date, because I've been exclusively using CKAN since KSP 0.25.

...but most of these mods are as simple and dumb as nearly any other mod to install. I've done manual installations of TextureReplacer, ATM, Distant Object, VSR (without the pruning method), EVE, CollisionFX without any issues and without any conflicts. Then, Smokescreen isn't a stand-alone, it's a dependency for things like RealPlume. And RealPlume and HotRockets both fall under "seen it coming a mile away" because both mess with the same system: engine exhaust particles.

Well, clearly, you know a lot more about how mods interact with the game than I do. That's obvious, really, since you needed to understand it in order to start modding, and you're an extremely accomplished modder. I just want to be able to use interesting mods on a cool game without having to mess about too much.

None of those alone have any reason to need CKAN, AFAICT.

Alone, no. That's not the point. It's when you are having to deal with dozens of mods that CKAN becomes a necessity, at least for some of us. Why can't you see that?

If it uses a common version, you can always upgrade, because dependencies rarely break compatibility; the only time it has ever happened was when CKAN ended up distributing an in-development version of a dependency instead of the actual release version that it should have.

You mean the in-development firespitter.dll that a bunch of modders starting distributing and relying on, forcing CKAN to include it?

As for other OSes, thanks to the wonder that is coding in C# and JIT compilation, we don't need to care.

And so you don't. And sometimes, that adds to the difficulties just a little. Edited October 27, 2015 by politas

[Olympic1]

@ferram4, @politas, is this still ongoing?

[ferram4]

No, I don't deny that. But that is not what you said that I objected to. You said that when anything went wrong, the first thing the CKAN maintainers do is throw everything on the modders. The discussions I've seen on the NetKAN github do not support that conclusion.

Except nearly every discussion includes, "we can get modders to contribute metadata!" Or, "we can get modders to tell us whether this update is safe or not!" Or any other sort of thing to drag us into something where it shouldn't be necessary.

But you are correct, I took it as "we don't test the metadata," which is apparently true.

The assumption is that mods stay basically the same, with the same requirements. If the dependencies change radically, then yes, things will get screwed up. That is definitely a flaw in the CKAN model, but testing every metadata change is simply not a practical goal for CKAN maintainers. CKAN is tracking over a thousand mods, and there are only a handful of contributors.

And at this point, you're basically saying that for all of CKAN's goal of making installs more reliable and more likely to be perfect, it will always fall behind a perfect manual install... And that you've got in over your heads on any attempt to fix that. See, this is a real problem, because I can't know every mod that someone has installed when they come with problems, nor can I know which mods have recently been screwed up in CKAN installs.

I never said anything about testing metadata releases.

Maybe you should look into it, it would go a long way to fixing all the issues. If you had a system that didn't need metadata like the other mod managers do, then we wouldn't even have this problem.

Why can't you just be as perfect under perfect instructions as a manual installation? Why isn't that on the table?

I didn't say you were lying, I said that your claim was not true; that you were mistaken. I easily believe that users are having FAR installs not working through CKAN. I haven't managed to get a working FAR installation since KSP 1.0 came out, myself. My solution so far is to not use it in the hope that it'll get fixed eventually.

Don't expect it to. There's no incentive to fix it.

Maybe it's been fixed since I started using CKAN. I know that I ended up with two different versions of Module Manager trying to run simultaneously at one point, thanks to a mod that included a ModuleManager.*.*.dll in a subdirectory. That particular problem may well have been fixed by now. All my examples of what drove me to CKAN are out of date, because I've been exclusively using CKAN since KSP 0.25.

...that was fixed a long time ago. I don't even remember which KSP version that was fixed in. Also, it's slightly telling, but I suppose that's understandable. CKAN is supposed to hide all the mess and let you remain unaware of what's going on under the hood, for better or for worse, right?

Well, clearly, you know a lot more about how mods interact with the game than I do. That's obvious, really, since you needed to understand it in order to start modding, and you're an extremely accomplished modder. I just want to be able to use interesting mods on a cool game without having to mess about too much.

And back before CKAN, you didn't need to be an accomplished modder to use any of that, and you didn't have to mess with it at all. Also, I knew less about mod interactions when I started modding than most users do now (even after CKAN seems to have reduced user knowledge about how mods work). If you'd mentioned planet packs + EVE + configs for EVE< then maybe I'd entertain the notion, but outside things like that, very little knowledge of modding is needed to figure that sort of thing out.

Alone, no. That's not the point. It's when you are having to deal with dozens of mods that CKAN becomes a necessity, at least for some of us. Why can't you see that?

I do see that, and I don't understand why. It's the same install steps for nearly every mod, you just have to repeat them... and when you find a bug or something, check for an update on what you might think is the problem. I don't see where the need for it is. I don't see where the install improvements are, especially once you consider the times it completely screws up. I get to see worse than the CKAN sausage being made: I get to pick through it and see a bunch of things gone wrong. Why can't you see that?

You mean the in-development firespitter.dll that a bunch of modders starting distributing and relying on, forcing CKAN to include it?

No, I mean when it distributed an old version of ModularFlightIntegrator and caused crashes when people installed FAR + DRE. CKAN screwed the pooch real bad there.

And so you don't. And sometimes, that adds to the difficulties just a little.

I can count only three OS-specific issues that I've ever had to deal with:

1) Mac OS overwrite-folders-by-default-rather-than-merge in installs

2) win64 KSP build crashiness

3) Unity FloatCurve implementation on Linux that could create NaNs.

And that's in a few years of modding. There are almost no OS-specific mod issues unless someone is seeking to cause them or if it's in the engine. Everything else is similar enough to not matter.

[Hektos]

I do see that, and I don't understand why. It's the same install steps for nearly every mod, you just have to repeat them... and when you find a bug or something, check for an update on what you might think is the problem. I don't see where the need for it is. I don't see where the install improvements are, especially once you consider the times it completely screws up. I get to see worse than the CKAN sausage being made: I get to pick through it and see a bunch of things gone wrong. Why can't you see that?

Back before CKAN there weren't exactly a whole lot of mods even worth installing (imo) and maintaining a list of ~10-20 mods wasn't big deal. Now, you've got multitudes of wonderful mods that contribute to a fun game experience and maintaining a list of 50+ mods suddenly becomes a bit of a chore.

Sure, installing mods is quite a simple affair, but CKAN brings the convenience of selecting the mods you want and walking away to do something else while it does the tedious things. It saves time which, you seem like someone who can appreciate, is in quite short supply for anyone who has a full time job and/or family.

To me, the idea of CKAN was always about convenience and time saving. There isn't a NEED for CKAN, but it's there to save time and (in some cases) confusion.

[passinglurker]

So from what I'm getting out of this is in order to properly maintain a system like ckan a maintainer needs to have the same skills as a manual installer in knowing how mods work and interact and taking the time to manually test things.

In other words there is a fundamental flaw that ckan needs people who dont need ckan to keep it running so it's hard to attract maintainers, but this man power shortage could be solved if mods authors could be pressured into doing this testing and metadata work like they would have to do if kerbal had steam workshop support, but people who support larger mods, multiple mods, or plugins don't want to take the time to do these things believing they have enough on thier plate already because they have filled the time they would have spent generating working meta data with even more mod development, and anyone else who enters the community who would be qualified for maintaining ckan would probably either rather enter mod development instead, or see no benefit for themselves because they can take care of themselves.

Am I getting warm?

It sounds to me like ckan is over extended it can't handle letting in every mod on KS. I'm sure it's a great exposure and update notification tool though perhaps it should drop automatic installation? Not permanently of course just until it can reliably id and install simple part mods and then only for those mods before steadily expanding to more complex mods and plugins from there as the automation tool matures. Instead of trying to shape the community to give it the man power it would other wise need to support every mod under the sun all at once from the start. Meanwhile complex mods would still be available on ckan where it will notify and download updates it would just require the user to merge the files themselves to insure it is done properly. It can even be used to provide easy to find installation instructions.

TLDR: scale ckan back to something like avc but with the benefit of also being a mod discovery and exposure tool until the automation matures.

[politas]

But you are correct, I took it as "we don't test the metadata," which is apparently true.

We don't test every release of the metadata, certainly. Mods that aren't a single folder with the same name as the mod name generally do get initial testing. But now it's starting to sound like we're getting to the heart of the problem being NetKAN, rather than CKAN itself.

And at this point, you're basically saying that for all of CKAN's goal of making installs more reliable and more likely to be perfect, it will always fall behind a perfect manual install...

I think that's always been the understanding. It is much easier than a perfect manual installation, which is the primary goal. The problem CKAN tries to fix isn't "perfect manual installations", it's "imperfect manual installations".

And that you've got in over your heads on any attempt to fix that. See, this is a real problem, because I can't know every mod that someone has installed when they come with problems, nor can I know which mods have recently been screwed up in CKAN installs.

With manual installs, it's very hard to know every mod someone has installed. It's pretty easy to forget mods that aren't in your face. I don't see how CKAN makes any of this worse when users come to you with complaints. Even without CKAN, you can't assume perfect installations. CKAN will at least give users a list of all the mods they've installed with it.

Maybe you should look into it, it would go a long way to fixing all the issues. If you had a system that didn't need metadata like the other mod managers do, then we wouldn't even have this problem.

I already mentioned that testing every new version release of over a thousand mods is not a practical goal for a handful of time-limited volunteers. What kind of mod manager doesn't need metadata?

I do see that, and I don't understand why.

Well, I've tried to explain all the things I experienced that are the why for me, and your response has been to dismiss each of them as not a problem.

* Mod packages are not discreet units and an upgrade to a dependency can break things

* Installed mods are not always simple to uninstall (folder names can be pretty random), so I needed to go looking in the downloaded zip file to check where the installed files were

* Keeping track of every mod installed meant building my own filing system for tracking things

* Every plugin mod has the potential to interact poorly with other plugin mods, so I needed to revisit the entire list of installed mods before installing any new mod and gain some basic level of understanding not simply what each mod was supposed to do, but how it did it, and revisit all of those factors for the whole mod list every time I wanted to try a new mod. The number of comparisons starts to get ridiculous after a while

* Mod management was taking up all the time I had available for gaming

It's the same install steps for nearly every mod, you just have to repeat them... and when you find a bug or something, check for an update on what you might think is the problem. I don't see where the need for it is. I don't see where the install improvements are, especially once you consider the times it completely screws up. I get to see worse than the CKAN sausage being made: I get to pick through it and see a bunch of things gone wrong. Why can't you see that?

I can see that. At no point in this discussion have I denied that there is a problem that needs to be dealt with. I don't see the problems CKAN causes as worse than the hell I was getting myself into before I found it, so I'm not interested in solutions that involve getting rid of it.

No, I mean when it distributed an old version of ModularFlightIntegrator and caused crashes when people installed FAR + DRE. CKAN screwed the pooch real bad there.

Ouch. Sounds nasty. But I gather that's been fixed?

I can count only three OS-specific issues that I've ever had to deal with:

1) Mac OS overwrite-folders-by-default-rather-than-merge in installs

2) win64 KSP build crashiness

3) Unity FloatCurve implementation on Linux that could create NaNs.

And that's in a few years of modding. There are almost no OS-specific mod issues unless someone is seeking to cause them or if it's in the engine. Everything else is similar enough to not matter.

Well, it's not surprising that you haven't come across the worst Linux issue that I came across, a bug in the Linux AMD driver that under some circumstances causes whole desktop lockup on loading certain PNG files, such as the ones in EVE. I could consistently make my computer freeze by loading EVE's kerbin1.png in an image viewer, much less in KSP. (Had to buy a new graphics card to avoid that one!)

- - - Updated - - -

So from what I'm getting out of this is in order to properly maintain a system like ckan a maintainer needs to have the same skills as a manual installer in knowing how mods work and interact and taking the time to manually test things.

In other words there is a fundamental flaw that ckan needs people who dont need ckan to keep it running so it's hard to attract maintainers, but this man power shortage could be solved if mods authors could be pressured into doing this testing and metadata work like they would have to do if kerbal had steam workshop support, but people who support larger mods, multiple mods, or plugins don't want to take the time to do these things believing they have enough on thier plate already because they have filled the time they would have spent generating working meta data with even more mod development, and anyone else who enters the community who would be qualified for maintaining ckan would probably either rather enter mod development instead, or see no benefit for themselves because they can take care of themselves.

Am I getting warm?

More than warm, I'd say

It sounds to me like ckan is over extended it can't handle letting in every mod on KS. I'm sure it's a great exposure and update notification tool though perhaps it should drop automatic installation? Not permanently of course just until it can reliably id and install simple part mods and then only for those mods before steadily expanding to more complex mods and plugins from there as the automation tool matures. Instead of trying to shape the community to give it the man power it would other wise need to support every mod under the sun all at once from the start. Meanwhile complex mods would still be available on ckan where it will notify and download updates it would just require the user to merge the files themselves to insure it is done properly. It can even be used to provide easy to find installation instructions.

TLDR: scale ckan back to something like avc but with the benefit of also being a mod discovery and exposure tool until the automation matures.

I think there is perhaps some over-extension. The flood of new mods that have been arriving since the KSP 1.0 release has been taxing the resources and dedication of the NetKAN contributors. You might have a good idea in there to have a metadata flag that stops CKAN doing an automated install for certain complex and/or fundamental mods. That sounds like it would answer Ferram's main concern. I don't think removing automated installs completely would go down well with CKAN users.

Ferram, does that sound close enough to the "option to de-list" you were talking about? If so, I'll raise it as an issue and evangalise it.

Edited October 28, 2015 by politas
Wrong filename

[passinglurker]

More than warm, I'd say

I think there is perhaps some over-extension. The flood of new mods that have been arriving since the KSP 1.0 release has been taxing the resources and dedication of the NetKAN contributors. You might have a good idea in there to have a metadata flag that stops CKAN doing an automated install for certain complex and/or fundamental mods. That sounds like it would answer Ferram's main concern. I don't think removing automated installs completely would go down well with CKAN users.

Ferram, does that sound close enough to the "option to de-list" you were talking about? If so, I'll raise it as an issue and evangalise it.

The idea is not the same as de-listing which would mean a mod can't be found in CKAN. Rather that CKAN can alternatively be used as an aid in manual installation when it can't reliably do the job itself.

Even without automatic installation CKAN is still a medium for mods to be discovered, gain exposure, and distribute update notifications meaning even if it can't install it can still perform downloads at least. Additionally it's a great way to put specific installation instructions in the user's face. Add an integrated archive extractor/file browser between your game data folder and your mods zip file and it'd be golden. The perfect lazy man's "cram two file browser windows and a web browser all on one screen" set up

EDIT: All that being said even after all that effort to aid manual installs if a mod author wants to genuinely de-list then his request should be honored as quickly as possible.

Edited October 28, 2015 by passinglurker

[politas]

I've just added a manual install of FAR to a heavily-CKAN-modded install (somewhere over 140 mods by CKAN's count) and it seems to have worked fine. Flaps and spoilers work as they ought to, a flat spin is basically unrecoverable, landing is bloody hard,... All the stuff I expect from FAR. As an interim step, I might add a note to CKAN's description of FAR recommending manual installation.

[ferram4]

Back before CKAN there weren't exactly a whole lot of mods even worth installing (imo) and maintaining a list of ~10-20 mods wasn't big deal. Now, you've got multitudes of wonderful mods that contribute to a fun game experience and maintaining a list of 50+ mods suddenly becomes a bit of a chore.

...but virtually all the mods that we have now existed before CKAN. Nearly every mod listed under Realism Overhaul for whatever purpose existed before CKAN; as I understood it part of the reason behind CKAN was to simplify that install.

I haven't seen an explosion of mods since CKAN has existed; all the main ones have been there from long before, many of the minor ones as well, and a few others on the side. Not much has changed in terms of what mods exist, AFAICT.

We don't test every release of the metadata, certainly. Mods that aren't a single folder with the same name as the mod name generally do get initial testing. But now it's starting to sound like we're getting to the heart of the problem being NetKAN, rather than CKAN itself.

And for me, what's the difference? The tool causes problems installing, and no one makes sure it's not running on garbage.

I think that's always been the understanding. It is much easier than a perfect manual installation, which is the primary goal. The problem CKAN tries to fix isn't "perfect manual installations", it's "imperfect manual installations".

Except when it manages to replace "perfect manual installations" with "imperfect automatic installations" then there's a really big problem, because it's going to do the same thing to people who would have had "imperfect manual installations" as well. At that point, you just have more broken installations.

With manual installs, it's very hard to know every mod someone has installed.

Not really. Plugins are the source of most bugs, those show up in the logs assuming that they've been loaded. Anything involving pure part packs is rare, and when it isn't usually requires lots of testing until a specific problem-part gets found out; CKAN doesn't help there at all.

The only thing that CKAN has done in terms of mods installed is to generally increase the number of mods people have installed, which is not a good thing from a bug-fixing POV, I'll tell ya. Sadly, for all its supposed use in making installing/uninstalling easier, it also doesn't seem to encourage people to follow through with requests to reproduce the issue with the minimum mods involved, so it just means more confounders for me to deal with.

I already mentioned that testing every new version release of over a thousand mods is not a practical goal for a handful of time-limited volunteers. What kind of mod manager doesn't need metadata?

Well, the lack of testing means more issues. Also, KSP Mod Admin and TinkerTime never needed metadata, so I don't know why you guys need it.

Well, I've tried to explain all the things I experienced that are the why for me, and your response has been to dismiss each of them as not a problem.

* Mod packages are not discreet units and an upgrade to a dependency can break things

* Installed mods are not always simple to uninstall (folder names can be pretty random), so I needed to go looking in the downloaded zip file to check where the installed files were

* Keeping track of every mod installed meant building my own filing system for tracking things

* Every plugin mod has the potential to interact poorly with other plugin mods, so I needed to revisit the entire list of installed mods before installing any new mod and gain some basic level of understanding not simply what each mod was supposed to do, but how it did it, and revisit all of those factors for the whole mod list every time I wanted to try a new mod. The number of comparisons starts to get ridiculous after a while

* Mod management was taking up all the time I had available for gaming

And while I understand that, I don't think those are actually as big a deal as you say. Nearly every dependency is backwards compatible, except KSPAPI, and that's designed to have multiple copies in eahc mod directory to alleviate that. Uninstall, yeah, that's true, but CKAN doesn't do a much better job, considering it can and will leave things behind. Keeping track of mods installed (to me) is just looking in GameData, and for most plugins, despite what people tell you you don't need to worry unless they're working on the exact same thing. Mod management I can see if you're constantly checking for updates, but that's why I don't expect people to update right away and why I don't release updates fast.

I can see that. At no point in this discussion have I denied that there is a problem that needs to be dealt with. I don't see the problems CKAN causes as worse than the hell I was getting myself into before I found it, so I'm not interested in solutions that involve getting rid of it.

And I don't see any of the problems that CKAN claims to have fixed as being worth the extra effort and difficulty that it's created me, so I'm not interested in any solutions that don't remove all of the extra hassle CKAN has created.

Ouch. Sounds nasty. But I gather that's been fixed?

Yes, after it finally became apparent that CKAN was the cause. Spent a fair bit of time trying to figure out what in FAR or DRE might cause a sudden burst of memory to get allocated, since OOM errors are really the only way that KSP crashes.

Well, it's not surprising that you haven't come across the worst Linux issue that I came across, a bug in the Linux AMD driver that under some circumstances causes whole desktop lockup on loading certain PNG files, such as the ones in EVE. I could consistently make my computer freeze by loading EVE's kerbin1.png in an image viewer, much less in KSP. (Had to buy a new graphics card to avoid that one!)

Okay, that is bad. Yeah, I've been lucky with no driver stuff.

So from what I'm getting out of this is in order to properly maintain a system like ckan a maintainer needs to have the same skills as a manual installer in knowing how mods work and interact and taking the time to manually test things.

In other words there is a fundamental flaw that ckan needs people who dont need ckan to keep it running so it's hard to attract maintainers, but this man power shortage could be solved if mods authors could be pressured into doing this testing and metadata work like they would have to do if kerbal had steam workshop support, but people who support larger mods, multiple mods, or plugins don't want to take the time to do these things believing they have enough on thier plate already because they have filled the time they would have spent generating working meta data with even more mod development, and anyone else who enters the community who would be qualified for maintaining ckan would probably either rather enter mod development instead, or see no benefit for themselves because they can take care of themselves.

Am I getting warm?

That's pretty close. Only modification I'd add is that I personally (and this probably doesn't extend to all other modders that have problems with CKAN), generally find the idea that modders should fix CKAN's issues to be the kind of situation that creates a moral hazard. If CKAN can create an issue for modders, and then modders can be relied on to step in to fix it (under pain of users clogging support channels until they do), what incentive does CKAN have to make sure that things work well? If someone else will do the support work and then catch flak for not doing it immediately while CKAN gets all the glory and none of the complaints, why should they make it work exactly right at first?

TLDR: scale ckan back to something like avc but with the benefit of also being a mod discovery and exposure tool until the automation matures.

Except I don't think that's likely to happen. That would basically undermine the entire thing that people value about CKAN, the "click-button-receive-mod" idea of it. Especially since CKAN has built so much of it up over that, it would cause a tremendous uproar. Granted, I'd find it hilarious, but that's not what any of the CKAN contributors want.

More than warm, I'd say

I think there is perhaps some over-extension. The flood of new mods that have been arriving since the KSP 1.0 release has been taxing the resources and dedication of the NetKAN contributors. You might have a good idea in there to have a metadata flag that stops CKAN doing an automated install for certain complex and/or fundamental mods. That sounds like it would answer Ferram's main concern. I don't think removing automated installs completely would go down well with CKAN users.

Ferram, does that sound close enough to the "option to de-list" you were talking about? If so, I'll raise it as an issue and evangalise it.

Attempting something more limited is possibly more viable, but I can explain exactly why that'll never happen. It's the same reason that pjf has told me that FAR is basically never being de-listed under any circumstance: Realism Overhaul and similar large mod groupings. CKAN is supposed to handle those automatically, right? Not handling them automatically defeats the entire purpose of CKAN, just as de-listing FAR would make installing RO through CKAN impossible.

Also, cynical me expects that it wouldn't be allowed simply on the basis that admitting imperfection would undermine the value of CKAN in the eyes of its users, so that can't be allowed. Even if it leads to more perfect installs.

The idea is not the same as de-listing which would mean a mod can't be found in CKAN. Rather that CKAN can alternatively be used as an aid in manual installation when it can't reliably do the job itself.

Even without automatic installation CKAN is still a medium for mods to be discovered, gain exposure, and distribute update notifications meaning even if it can't install it can still perform downloads at least. Additionally it's a great way to put specific installation instructions in the user's face. Add an integrated archive extractor/file browser between your game data folder and your mods zip file and it'd be golden. The perfect lazy man's "cram two file browser windows and a web browser all on one screen" set up

EDIT: All that being said even after all that effort to aid manual installs if a mod author wants to genuinely de-list then his request should be honored as quickly as possible.

As I said above, I doubt there'd be any traction on this because it undermines what's supposed to be one of CKAN's big things.

I've just added a manual install of FAR to a heavily-CKAN-modded install (somewhere over 140 mods by CKAN's count) and it seems to have worked fine. Flaps and spoilers work as they ought to, a flat spin is basically unrecoverable, landing is bloody hard,... All the stuff I expect from FAR. As an interim step, I might add a note to CKAN's description of FAR recommending manual installation.

Not trying to be mean, but this does make me cackle just a little bit. Best illustration of what I said evar.

Okay, serious talk and not arguing: the metadata _could_ in theory be tested reliably by computer. You would need a program to do a manual "install" by extracting the zip file (based on any of the two or three standard folder structures or based on existing CKAN metadata) and then do a CKAN-based "install" in another folder. Go through the folders and check hashes to see if the files are identical and check paths to make sure they're in identical directories. Only place things won't perfectly match up is for dependencies; CKAN should know those and be able to identify them from the CKAN-based install. Don't check the manual dependency's file against the installed dependency, instead check all the possible CKAN versions of that.

Only two failure points here: 1) dependencies aren't up-to-date in CKAN, but that can be fixed by repeating the test later and 2) the zip file has a very strange folder structure, which requires human eyes. In either case though, failure grabs human eyes for it.

[politas]

...but virtually all the mods that we have now existed before CKAN. Nearly every mod listed under Realism Overhaul for whatever purpose existed before CKAN; as I understood it part of the reason behind CKAN was to simplify that install.

I haven't seen an explosion of mods since CKAN has existed; all the main ones have been there from long before, many of the minor ones as well, and a few others on the side. Not much has changed in terms of what mods exist, AFAICT.

The big main ones, sure, though so much changed in KSP 1.0 that significant changes have happened in a lot of them, including FAR and DRE. There is a stream of new parts mods showing up on Kerbalstuff, though. They usually don't require a lot of testing, but they almost always require a bit of attention by the NetKAN contributors. Most of which gets sorted out without any bother to the modders.

The only thing that CKAN has done in terms of mods installed is to generally increase the number of mods people have installed, which is not a good thing from a bug-fixing POV, I'll tell ya. Sadly, for all its supposed use in making installing/uninstalling easier, it also doesn't seem to encourage people to follow through with requests to reproduce the issue with the minimum mods involved, so it just means more confounders for me to deal with.

It's hard to get casual gamers to do thorough testing in any case. CKAN's simple uninstall/reinstall mechanism makes it easier to cut out possible confounders.

KSP Mod Admin and TinkerTime never needed metadata, so I don't know why you guys need it.

I've never heard of those, and don't know what kind of functionality they provided. Searching the forums has been fruitless. Without that information, I cannot assess their comparative utility.

And while I understand that, I don't think those are actually as big a deal as you say.

You've made your opinion on that matter clear over and over. I'm not asking you to change your opinion on whether CKAN is needed, I'm asking you simply to accept that they are a big deal for people who are not you. They are a big deal for me. They stopped me be able to enjoy the game. I don't want to spend my leisure time playing the "get a working installation of KSP with loads of interesting mods" game.

That's pretty close. Only modification I'd add is that I personally (and this probably doesn't extend to all other modders that have problems with CKAN), generally find the idea that modders should fix CKAN's issues to be the kind of situation that creates a moral hazard. If CKAN can create an issue for modders, and then modders can be relied on to step in to fix it (under pain of users clogging support channels until they do), what incentive does CKAN have to make sure that things work well? If someone else will do the support work and then catch flak for not doing it immediately while CKAN gets all the glory and none of the complaints, why should they make it work exactly right at first?

Because CKAN contributors want CKAN to work exactly right for the exact same reasons you want FAR to work exactly right.

Except I don't think that's likely to happen. That would basically undermine the entire thing that people value about CKAN, the "click-button-receive-mod" idea of it. Especially since CKAN has built so much of it up over that, it would cause a tremendous uproar. Granted, I'd find it hilarious, but that's not what any of the CKAN contributors want.

Attempting something more limited is possibly more viable, but I can explain exactly why that'll never happen. It's the same reason that pjf has told me that FAR is basically never being de-listed under any circumstance: Realism Overhaul and similar large mod groupings. CKAN is supposed to handle those automatically, right? Not handling them automatically defeats the entire purpose of CKAN, just as de-listing FAR would make installing RO through CKAN impossible.

It's not an ideal solution from CKAN's perspective, but if CKAN's autodetection can be improved enough that it can recognise and log the version of a manually installed mod, then the issue of dependencies could be handled. Every mod that insisted on manual installation would be a headache for users, of course. Ignore for now whether the CKAN developers would like it; would it be an acceptable compromise for you?

Okay, serious talk and not arguing: the metadata _could_ in theory be tested reliably by computer. You would need a program to do a manual "install" by extracting the zip file (based on any of the two or three standard folder structures or based on existing CKAN metadata) and then do a CKAN-based "install" in another folder. Go through the folders and check hashes to see if the files are identical and check paths to make sure they're in identical directories. Only place things won't perfectly match up is for dependencies; CKAN should know those and be able to identify them from the CKAN-based install. Don't check the manual dependency's file against the installed dependency, instead check all the possible CKAN versions of that.

Only two failure points here: 1) dependencies aren't up-to-date in CKAN, but that can be fixed by repeating the test later and 2) the zip file has a very strange folder structure, which requires human eyes. In either case though, failure grabs human eyes for it.

A lot of that is already done by a validation program. Exactly how much of it, I'm not sure, since I haven't been involved in the development of that program. I don't think it actually runs a CKAN instance in comparison to a simple unzip to test the download. I'm not sure how effective that would be. If if the "manual install" is based on old CKAN metadata, then I can't see it being useful at all.

[politas]

I've just added a manual install of FAR to a heavily-CKAN-modded install (somewhere over 140 mods by CKAN's count) and it seems to have worked fine. Flaps and spoilers work as they ought to, a flat spin is basically unrecoverable, landing is bloody hard,... All the stuff I expect from FAR. As an interim step, I might add a note to CKAN's description of FAR recommending manual installation.

Not trying to be mean, but this does make me cackle just a little bit. Best illustration of what I said evar.

Except that I have now done a manual uninstall of FAR on that same installation, reinstalled through CKAN, and it's exactly the same. No idea what the heck you're complaining about. It worked perfectly, just like you want.

[ferram4]

It's hard to get casual gamers to do thorough testing in any case. CKAN's simple uninstall/reinstall mechanism makes it easier to cut out possible confounders.

Casual gamers rarely report bugs at all, and the people that have reported bugs and are using CKAN seem even more resistant to testing. I somewhat suspect that relying on the group that selects the path of least (apparent) resistance also reduces the willingness to bugfix.

I've never heard of those, and don't know what kind of functionality they provided. Searching the forums has been fruitless. Without that information, I cannot assess their comparative utility.

Further down in this very forum:

http://forum.kerbalspaceprogram.com/threads/85865-Tinker-Time-Self-Updating-Curse-com-Mod-Manager-for-KSP

http://forum.kerbalspaceprogram.com/threads/26031-AnyOS-KSP-Mod-Admin-v2-Mod-install-with-a-few-clicks

They've been around a lot longer than CKAN every has been.

Because CKAN contributors want CKAN to work exactly right for the exact same reasons you want FAR to work exactly right.

Except one of the largest incentives for making FAR work exactly right is reducing support requests for me, and thus, workload, and we already established that modders get all the support requests due to CKAN screwups, so that incentive isn't there for CKAN.

It's not an ideal solution from CKAN's perspective, but if CKAN's autodetection can be improved enough that it can recognise and log the version of a manually installed mod, then the issue of dependencies could be handled. Every mod that insisted on manual installation would be a headache for users, of course. Ignore for now whether the CKAN developers would like it; would it be an acceptable compromise for you?

First, I'm not arguing that CKAN developers wouldn't like it; I'm arguing they'd never accept it. It's already been established to me by pjf that anything that involves FAR not being available for the standard CKAN treatment is pretty much unacceptable and so won't happen if he can prevent it.

Second, I would like to say that it would be acceptable. In practice, while I have no doubt it would raise the barrier to entry sufficiently, given the behavior I've seen from CKAN users when they want a mod that isn't on CKAN to be on CKAN, I expect that any mod like that would immediately be inundated with demands to make it auto-install capable, thanks to the expectations you've already set. Well, at that point, now it being on CKAN but not installable also causes more problems, and the only acceptable option is full de-listing. Which is not ever going to happen, we both know it, at that point CKAN doesn't even need to respect ARR + "nothing to do with CKAN ever" clause if it's just saying, "this thing is here and is nice." I have very strong reservations about how it would work in practice. You guys really opened a nasty bottle with this thing.

A lot of that is already done by a validation program. Exactly how much of it, I'm not sure, since I haven't been involved in the development of that program. I don't think it actually runs a CKAN instance in comparison to a simple unzip to test the download. I'm not sure how effective that would be. If if the "manual install" is based on old CKAN metadata, then I can't see it being useful at all.

Well, if the CKAN metadata is missing a bundled dependency, running the extract test would catch it. If the old metadata isn't capable of creating an old install, the extract test would catch it.

Except that I have now done a manual uninstall of FAR on that same installation, reinstalled through CKAN, and it's exactly the same. No idea what the heck you're complaining about. It worked perfectly, just like you want.

And you told me that you've run the principle of "if it's not on CKAN, it may as well not exist" and that you had install errors with FAR; ergo, CKAN caused FAR install errors for you. Not seeing how I'm wrong there.

Yes, it might work now after I've screamed enough, but that's not guaranteed for the next FAR or KSP update.

[politas]

http://forum.kerbalspaceprogram.com/threads/85865-Tinker-Time-Self-Updating-Curse-com-Mod-Manager-for-KSP

http://forum.kerbalspaceprogram.com/threads/26031-AnyOS-KSP-Mod-Admin-v2-Mod-install-with-a-few-clicks

They've been around a lot longer than CKAN every has been.

Searching on these forums can be very difficult. Ok. I see that they both do a small subset of what CKAN does. Neither appears to handle to problems of dependency cross-upgrades, apart from Module Manager.

Except one of the largest incentives for making FAR work exactly right is reducing support requests for me, and thus, workload, and we already established that modders get all the support requests due to CKAN screwups, so that incentive isn't there for CKAN.

I don't believe we have established that. You keep claiming it, and I've denied it. There's even a special thread that's been created for FAR installed via CKAN, so that support requests can be moved somewhere you don't have to deal with them. CKAN contributors are bending over backwards there just to help you in particular, and you don't appear to even acknowledge that fact (although you have it mentioned in the FAR thread top post.) You have repeatedly said in this discussion that you just wish CKAN would go away. At this stage, I just wish you'd go away, and FAR with you. Clearly, lots of users like your mod and want to use it, so that's not going to happen.

And you told me that you've run the principle of "if it's not on CKAN, it may as well not exist" and that you had install errors with FAR; ergo, CKAN caused FAR install errors for you. Not seeing how I'm wrong there.

I don't know what caused my earlier problems. There were a bunch of realism mods I had installed, including FAR, and the game got a bit wonky, and I tried removing things gradually. FAR wasn't a particular "must-have" for me, so I wasn't too concerned about keeping it. Having now read a lot more of your crusade against CKAN, I think part of the trouble I had might have been the uninstall of FAR not cleaning up the FAR-created files, causing other mods to think FAR was installed when it wasn't. I've been going through the hassle of changing Linux graphics drivers, that involved a lot more serious computer issues for me than whether any particular mod was working. I gather the trouble with the incorrect ModuleFlightIntegrator version was caused by your inconsistent version numbering not alpha-sorting correctly.

Yes, it might work now after I've screamed enough, but that's not guaranteed for the next FAR or KSP update.

Of course not. Nothing is guaranteed to be perfect straight away. Especially since your antipathy towards CKAN means you aren't helping CKAN to handle FAR properly.

[linuxgurugamer]

I'm writing a set of netkan files for the Arkas mod.

There are four configuration options:

1. No clouds

2. Low clouds

3. Med clouds

4. Full clouds

so, these are all packaged in a single file with the following directory structure:

Arkas
+-Gamedata
|+-Arkas
|
+-Cloud Support
 +-Low Cloud Cover Config
 |+-GameData
 | +-BoulderCo
 |
 +-Med Cloud Cover Config
 |+-GameData
 | +-BoulderCo
 |
 +-Full Cloud Cover Config
 |+-GameData
 | +-BoulderCo
 |
 +-GameData
  +-BoulderCo

So, under the Cloud Support, there are 4 directories. These are only used if cloud support is being installed.

Of these, the last GameData need to be always installed, and one of the others.

So, what I'm planning on doing is this:

Main arkas netkan, which has the following:

        "recommends": [ { "name"      : "Arkas-Config" } ],

And three arkas config netkans, one for low, med and full, each having the following:

       "provides": [
                "Arkas-Config"
        ],
        "conflicts": [
                {
                        "name": "Arkas-Config"
                }
        ]

The idea here is that each provides the Arkas-Config, but confict with any of the others.

Is this workable? or is there a better way?

FYI, I got the idea on how to do this from the PlanetShine files.

Thanks in advance

LGG

Edited October 29, 2015 by linuxgurugamer

[politas]

I'm writing a set of netkan files for the Arkas mod.

There are four configuration options:

1. No clouds

2. Low clouds

3. Med clouds

4. Full clouds

so, these are all packaged in a single file with the following directory structure:

Arkas
+-Gamedata
|+-Arkas
|
+-Cloud Support
 +-Low Cloud Cover Config
 |+-GameData
 | +-BoulderCo
 |
 +-Med Cloud Cover Config
 |+-GameData
 | +-BoulderCo
 |
 +-Full Cloud Cover Config
 |+-GameData
 | +-BoulderCo
 |
 +-GameData
  +-BoulderCo

So, under the Cloud Support, there are 4 directories. These are only used if cloud support is being installed.

Of these, the last GameData need to be always installed, and one of the others.

So, what I'm planning on doing is this:

Main arkas netkan, which has the following:

        "recommends": [ { "name"      : "Arkas-Config" } ],

And three arkas config netkans, one for low, med and full, each having the following:

       "provides": [
                "Arkas-Config"
        ],
        "conflicts": [
                {
                        "name": "Arkas-Config"
                }
        ]

The idea here is that each provides the Arkas-Config, but confict with any of the others.

Is this workable? or is there a better way?

FYI, I got the idea on how to do this from the PlanetShine files.

Thanks in advance

LGG

Not quite. Look at the EVE .netkans, and take a second look at the Planetshine ones. Change your "recommends" to a "depends" on the meta-package (after all, some kind of config is required.) Each of the config netkans should also include this:

"depends": [ { "name"      : "Arkas-Config" } ],

[linuxgurugamer]

Not quite. Look at the EVE .netkans, and take a second look at the Planetshine ones. Change your "recommends" to a "depends" on the meta-package (after all, some kind of config is required.) Each of the config netkans should also include this:

"depends": [ { "name"      : "Arkas-Config" } ],

The config is a recommend because the cloud configs are optional.

Thanks for the other comments.

- - - Updated - - -

So, here are the complete netkans. I am a bit concerned about the "find" command, are they correct?, and remember, the configs are optional since they are only for clouds, if desired:

{

"identifier" : "Arkas",

"$kref" : "#/ckan/kerbalstuff/1158",

"spec_version" : "v1.4",

"comment" : "PlanetPack",

"resources" :

{

"homepage" : "http://forum.kerbalspaceprogram.com/threads/13457"

},

"depends" :

[

{ "name" : "Kopernicus", "min version": "0.4" }

],

"recommends":

[ { "name" : "Arkas-Config" } ],

"install" :

[

{

"find" : "Arkas",

"install_to" : "GameData"

}

],

"suggests" :

[

{ "name" : "PlanetShine" },

{ "name" : "DistantObjectEnhancement" }

]

}

{

"spec_version" : "v1.4",

"identifier" : "Arkas-Config-Full-Clouds",

"name" : "Arkas Full Cloud configuration",

"$kref" : "#/ckan/kerbalstuff/1158",

"install": [

{

"find" : "Full Cloud Cover Config/GameData/BoulderCo",

"install_to": "GameData"

},

{

"find" : "Cloud Support/Gamedata/BoulderCo",

"install_to": "GameData"

}

],

"depends": [

{

"name" : "Arkas"

}

],

"provides": [

"Arkas-Config"

],

"conflicts": [

{

"name": "Arkas-Config"

}

]

}

{

"spec_version" : "v1.4",

"identifier" : "Arkas-Config-Low-Clouds",

"name" : "Arkas Low Cloud configuration",

"$kref" : "#/ckan/kerbalstuff/1158",

"install": [

{

"find" : "Low Cloud Cover Config/GameData/BoulderCo",

"install_to": "GameData"

},

{

"find" : "Cloud Support/Gamedata/BoulderCo",

"install_to": "GameData"

}

],

"depends": [

{

"name" : "Arkas"

}

],

"provides": [

"Arkas-Config"

],

"conflicts": [

{

"name": "Arkas-Config"

}

]

}

{

"spec_version" : "v1.4",

"identifier" : "Arkas-Config-Med-Clouds",

"name" : "Arkas Med Cloud configuration",

"$kref" : "#/ckan/kerbalstuff/1158",

"install": [

{

"find" : "Med Cloud Cover Config/GameData/BoulderCo",

"install_to": "GameData"

},

{

"find" : "Cloud Support/Gamedata/BoulderCo",

"install_to": "GameData"

}

],

"depends": [

{

"name" : "Arkas"

}

],

"provides": [

"Arkas-Config"

],

"conflicts": [

{

"name": "Arkas-Config"

}

]

}

[Olympic1]

The "find" command is to find a name of a folder and not a path, so use the "file" command to make use of a path.

you will also have to change the "spec_version" to:

"spec_version": 1

so no " " around the 1

[passinglurker]

So CKAN won't honor a modders request not to be listed? Honestly even if CKAN has a legal right to do so that constitutes an act of bad faith between CKAN and modders, and is poor conduct in general. Basically It's not how you make friends. I'm of the growing opinion that farram4 should seek for a change of forum rules for mod management services like ckan so that they can't list a mod against a modders wishes under penalty of the services discussion being removed from the forum.

Pressuring a modder into supporting any system under penalty of support requests is wrong. If CKAN wants to be believed that they are supporting FAR under their own efforts and not generating trouble for farram4 to pressure him then they would delist FAR until they have an extensively tested and working set up and when an update comes they can delist it again until they can generate another stable copy. Similar to how things are done in linux repositories you don't make something available to the end user until it works that simple.

But really complying with farram4 is a undeniably reasonable request. The law of navigation is that the more maneuverable yields to the least maneuverable. Ckan can more easily maneuver to delist FAR at farram4's request than farram4 can maneuver to support it. So the party at fault here who should be bending over backwards is CKAN.

Sure entitled users will complain during periods when FAR isn't available at first, but they will come to accept the routine eventually and its for the best to foster a good relationship between the mod management service and the mod other wise all that's left for farram4 is the nuclear option of suspending FAR development until CKAN folds(Ckan claims to need FAR not the other way around) or someone who wants to put up with CKAN adopts it (highly unlikely)