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

[ferram4]

You have just rejected, in very strong terms, an offer by someone to sort out the CKAN metadata for FAR - someone who is doing this for many mods and seems to have their head screwed on.

Perhaps that makes it harder to get things right?

...no I haven't. No one has asked about FAR metadata at all. I'm not sure how I could reject something that hasn't been asked. Go, check the FAR thread; there's nothing there about metadata.

You know, something I've noticed when dealing with CKAN: every person involved does their best to try and say, "no, we're not the ones screwing up, it must be your fault modder." Even to the point of making stuff up.

But let's suppose such a thing were to happen. FAR is not on CKAN by my choice. It was not added by me, nor have I ever had any input on the metadata. CKAN has always indexed my mods without ever asking for permission; I don't see why my permission is needed now, because it certainly wasn't needed before.

[damerell]

...no I haven't. No one has asked about FAR metadata at all. I'm not sure how I could reject something that hasn't been asked. Go, check the FAR thread; there's nothing there about metadata..

My mistake; it was in the KJR thread. (So, not "making stuff up", but honest confusion).

ferram, may I, with your permission, update the metadata in CKAN to use the new ranged formatting? This would set a ksp_version_min and _max, which would allow your mod's users who use CKAN to see it as "compatible" there, and install it easily rather than bothering you here in the forums. I can set the min to 1.0.2, and the max to 1.0.4 - making it available to people running any of those versions. I can also set the max to 1.0.99 meaning in all likelihood this mod is OK to use until 1.1 (the Unity 5 update). I will not do anything unless you say its OK, but after that it should cut down on questions here.

Reply:

I dunno why you're asking me, I have nothing to do with CKAN besides yelling at them about the problems they cause for me. Go take any of their problems to their place and please don't bring them here again.

Question stands; might this sort of response be in any way connected to the metadata not always being right for your mods?

Edited June 30, 2015 by damerell

[ferram4]

I have no idea how acknowledging that it's a CKAN problem, by whoever works with CKAN has anything to do with causing CKAN to screw up its metadata. It's not as if I'm the one that caused CKAN to index the wrong version of a dependency that only had one public version (how, I have no idea).

If he wants to update the metadata, well, CKAN policy and customs tell him he can do whatever he pleases. He never had to ask me, because CKAN established a long time ago that my permission doesn't matter. Why he wants it, I don't know; the only permission that I will give to CKAN is that they have the permission to de-index all my mods whenever they please; everything else is based on whatever other policies they have, and I won't pretend I have any say there.

[Ippo]

(I'll just point out that actually, you do. My offer is still valid, you know)

[ferram4]

Well, you've been overruled then. I tried that with pjf, and got a no. And it's a matter of CKAN policy that the answer is no. I don't think you actually can extend that offer anymore, unless you can somehow change the mind of everyone involved.

[Ippo]

Well, you've been overruled then. I tried that with pjf, and got a no. And it's a matter of CKAN policy that the answer is no. I don't think you actually can extend that offer anymore, unless you can somehow change the mind of everyone involved.

Well, I've been out of the game too long, it seems.

[pjf]

It's end of financial year here in Australia, which not only comes with an absolute boatload of legal reporting and paperwork for me, but has also had me interstate on work. I'm not likely to be back on the forums in any meaningful way for another couple of days until things quieten down. However, I am pleased to announce:

CKAN v1.10.0 aka "Rainbow Nebula" released

User visible changes since v1.8.4:

• [GUI/Bugfix] The GUI no longer says "about to remove" when there's nothing to remove (martinnj, #1203)
  
• [GUI/Bugfix] The client is more stable after cancelling a download (Postremus, #1185)
  
• [GUI/Bugfix] The auto-updater will try harder to set the execute bit when updating on Linux/Mac (Postremus, #1200)
  
• [GUI/Bugfix] The GUI is less likely to crash with an InconsistentKraken when related modules exist, but do not satisfy required version checks (RichardLake, #1219)
  
• [GUI/Feature] Double-clicking a row toggles mod selection (Postremus, #1217)
  
• [GUI/UX] The previously misleading 'delete' KSP instance is now 'forget' a KSP instance (Postremus, #1196)
  
• [GUI/UX] Even more dialog boxes have CKAN icons (Postremus, #1176)
  
• [Cmdline/Bugfix] Min/Max relationships are more accurately shown in ckan.exe show (dbent, #1183)
  
• [Cmdline/Feature] You can now ckan.exe remove --all to uninstall everything (martinnj, #1210)
  
• [Core/Bugfix] Bad URL resources will no longer cause a module to be considered invalid (pjf, #1209)
  
• [Core/Bugfix] Spurious messages are no longer produced for conditions that are actually okay (pjf, #1222)
  

Internal changes since v1.8.4:

• Many classes now use interfaces rather than hard dependencies (RichardLake, #1167)
  
• netkan.exe now strips x_netkan attributes during processing (dbent, #1193, #1201)
  
• netkan.exe now supports version-specific overrides (pjf, #1197)
  
• CKAN spec v1.10 now supports the find_regexp install directive (dbent, #1089)
  
• The human spec now matches the machine spec and current usage when describing version numbers (pjf, #1178)
  

Public Service Announcement:

We're aware that fewer mods than expected are showing for KSP v1.0.4. We're working overtime to fix this, and you can read the full details (including possible workarounds) here.

Note:

• Due to a change in the CKAN registry file format, you will not be able to move back to the 1.6.x releases after using this release.
  
• Windows users must have .NET 4.5 installed.
  
• Linux users, please apt-get install libcurl4-openssl-dev or yum install libcurl-devel if you have not already done so.
  
• Mac/Linux/Mono users: please mozroots --import --ask-remove if you're a new user, to update mono's certificate store.
  

[damerell]

If he wants to update the metadata, well, CKAN policy and customs tell him he can do whatever he pleases.

But Murdabenne's own desire to be polite led them to ask, politely; they're not part of some CKAN hive mind.

"Complains the metadata has been got wrong" and "bites the head off people endeavouring to get it right" don't seem entirely consistent positions to me. You could (for example) have replied "Go ahead, but it's not my problem and I'm not going to help you", which leaves you off the hook but would seem to increase the possibility it is got right, reducing the flood of CKAN-related enquiries (of which I could find one in the five pages of the FAR thread consumed by one confused-about-aerodynamics person).

[ferram4]

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now?

And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion. There was a good group of issues from way back of CKAN not installing MFI, then installing a version of MFI that caused problems with Deadly Reentry, which probably also involved issues being reported to that thread. Also, let me remind you: CKAN is a machine. It does the exact same thing every time. This affected everyone that used CKAN and FAR, not just the ones that reported it.

[damerell]

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now?

They asked permission; you didn't grant it. Now I know the hive-mind's position is that permission isn't needed, but that doesn't mean that an individual can't ask.

Seriously, as replies go, what exactly would be wrong with "Yes, but not my problem / don't expect any help / don't ask me how to do it" etc?

And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion.

I'm just saying, I think kookery is a far vaster source of noise. The "angle of attack is a conspiracy" chap went on quite a while too, as I recall.

(I've skipped some stuff we've done on github).

[nobodyhasthis]

They asked permission; you didn't grant it. Now I know the hive-mind's position is that permission isn't needed, but that doesn't mean that an individual can't ask. Seriously, as replies go, what exactly would be wrong with "Yes, but not my problem / don't expect any help / don't ask me how to do it" etc?

.

In this case it is a dead end because there is two overlapping conversations here. The point is if you do fix the metadata for FAR. You can cause more harm that good. Here what is missing...

Some End-users want more choices, so I have proposed (for discussion) having different modes of operation to allow the users the choice of how tight they want the checking:

strict -- must be released for the exact version, must be marked as such by the author. Its how things work now, pretty much the safest way, and this would be the default mode of function.

gras "generally recognized as safe" meaning although its compiled for 1.0, its OK to use on 1.0.2, 1.0.3, per the author (usually via a forum question or email) -- it looks like most falls into this category, (gras is also french for "fat" - as in a fat selection, lots of stuff). This saves addon authors time and effort when their users use CKAN to get updates.

forced which means the user overrides the version safety for this app (and its dependencies). Do this when your favorite addon isnt current but you want to install it anyway. This is akin to a manual install. The only thing you gain from CKAN is that it will check dependencies, and let you know when an update is available.

YOYO - You're On Your Own - doing this basically means you are unsupported and should not bother the authors of the addon or the authors of CKAN with errors you have created. Its like using Win64 mode - go for it, but dont go looking for support. The only thing CKAN does here is simply tell you what addons you have installed and give you pretty checkboxes to check and do an install,. or uncheck to uninstall.

This would make more people satisfied, allowing power users more leeway, but keeping most users in the safe zone.

(moved to its own post as a separate topic - a proposal for CKAN)

In this case we get more choice of how metadata is used. However with some mods like FAR. The option must be YOYO - You're On Your Own. Given the complex nature of the mod. There is overwhelming evidence that CKAN does not update FAR correctly. You can use CKAN and FAR but must accept the responsibility that it might cause a glitch in FAR.

I think forced == YOYO - as we know from past github issues, one reason the CKAN devs have (rightly, in my view) been reluctant to add a non-expert way to force installation is the inevitable tide of spurious bug reports.

I'd go so far as to suggest any forced/YOYO installation should leave a very prominent marker in output.log.

Yes indeed a very prominent marker. The same rule cuts both ways here. If we force a mod to work. Including forcing CKAN to work. Then we do so at our own risk and should not go crying to the mod creators.

[Capt.Mitch]

I came across a compatibility issue today with real solar system and custom asteroids where CKAN said they were not compatible. While I was looking into this I seen there is a patch in RSS folders. Is there a way to let CKAN know there is a patch and have it apply the patch when/if this applys?

[Metamucil Monk]

If I may make a suggestion for CKAN, would it be possible to add either the author's publish date for the current version of a mod or the most recent date of the upload to the repository to the details in the mod list?

[whaaw]

hi,

after the last update (gb447380) i got an error by clicking fast on the Update tab. ^^

Edit: its on all sorting rows

System.ArgumentOutOfRangeException: Der Index lag außerhalb des Bereichs. Er darf nicht negativ und kleiner als die Auflistung sein.

Parametername: index

bei System.Collections.ArrayList.get_Item(Int32 index)

bei System.Windows.Forms.DataGridViewRowCollection.get_Item(Int32 index)

bei CKAN.Main.ModList_CellMouseDoubleClick(Object sender, DataGridViewCellMouseEventArgs e)

bei System.Windows.Forms.DataGridView.OnMouseDoubleClick(MouseEventArgs e)

bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

bei System.Windows.Forms.Control.WndProc(Message& m)

bei System.Windows.Forms.DataGridView.WndProc(Message& m)

bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Edited June 30, 2015 by whaaw

[damerell]

In this case we get more choice of how metadata is used. However with some mods like FAR. The option must be YOYO - You're On Your Own. Given the complex nature of the mod. There is overwhelming evidence that CKAN does not update FAR correctly.

Oh, come on. It has been wrong in the past, which is regrettable, but while FAR does complex things, it does not have a complex set of dependencies.

[BlackHat]

I just tried installing CTT on my 1.0.4 install, and it didn't error, but I do have a ton of addons installed, do you still get this error after exiting, refreshing and retrying? I also tried GPOSpeedPump (which is GoodSpeed continues, installs as GoodSpeed directory) since its an addon I always have loaded as soon as its available, and its working too. Strange they should show an error - usually I am an error magnet for addons, if they break I break em.

- - - Updated - - -

For YOYO, I'd think not just a marker, but change the menu so that's the only mode you can use from then on, with appropriate warnings, popups, ominous sounds, and pictures of Walter White to indicate that you are now breaking (bad) the app.

Yes at the time (1.8.4? or 1.8.3?) it was repeatable. If I chose continue, the "Go to Changes" tab was greyed out, if I chose cancel CKAN crashed.

Now with 1.10, if I select CTT, the line turns red and I see a tool tip saying it conflicts with "OpenTree" mod and that CTT requested the not comparable status, (So I assume that was the actually cause before for the error message. as I have had OpenTree installed then too. {which is strange as I thought they WERE compatable, must be something recient)

[Recon777]

...I'm having a really, really difficult time finding how any of my response was biting the head off of someone. I explained that I was confused with the asking, that I don't deal with CKAN except for the problems that it causes for me, and that CKAN's problems are best kept to CKAN channels and with CKAN's people. Not wanting anything to do with CKAN and complaining that it has caused issues is being a jerk now?

Well, as someone relatively new to KSP and this community, seeing this unfold leads me to what one would think would be the most obvious solution...

Mod author does not want to be involved with CKAN, but is regularly burdened by CKAN-related inquiries from people who are not aware of the compatibility issues.

Mod author does not actually care if CKAN lists his mod if it were capable of installing the thing correctly.

Mod author prefers that people have his mod correctly installed and fully functional.

Mod author is irritated by the policies/conflict surrounding the CKAN people.

The most obvious solution from my perspective would be for the mod author to work with the CKAN people so that it installs the mod correctly, thus eliminating all CKAN-related inquiries from people having problems because they installed the mod with CKAN. As far as what "work with" looks like, from what I can tell, all it entails is simply saying "go for it". Nevermind that things have been done without permission already anyway and the request for permission seems to be an inconsistent policy. Who cares? If this whole thing can be resolved by saying "go for it" then why not do exactly that?

[nobodyhasthis]

Oh, come on. It has been wrong in the past, which is regrettable, but while FAR does complex things, it does not have a complex set of dependencies.

Unfortunately you not allowed to decide this. CKAN will decide for you. It will decide which version is best. You have no say in the matter. Move along.

[damerell]

Unfortunately you not allowed to decide this. CKAN will decide for you. It will decide which version is best. You have no say in the matter. Move along.

That's a complete non-sequitur, in no way addressing the point that FAR does not have a complex set of dependencies. This:

Replaces: heimdal-servers (<< 0.6.3-12)
Provides: ftp, rsh-client, telnet-client
Depends: krb5-config, libasn1-8-heimdal (>= 1.4.0+git20110226), libc6 (>= 2.11), libdb5.1, libedit2 (>= 2.11-20080614-1), libgssapi3-heimdal (>= 1.4.0+git20110226), libhcrypto4-heimdal (>= 1.4.0+git20110226), libhdb9-heimdal (>= 1.4.0+git20110226), libheimbase1-heimdal (>= 1.4.0+git20110226), libheimntlm0-heimdal (>= 1.4.0+git20110226), libhx509-5-heimdal (>= 1.4.0+git20110226), libkadm5clnt7-heimdal (>= 1.6~git20120311), libkadm5srv8-heimdal (>= 1.4.0+git20110226), libkafs0heimdal (>= 1.4.0+git20110226), libkrb5-26-heimdal (>= 1.6~git20120311), libotp0-heimdal (>= 1.4.0+git20110226), libroken18-heimdal (>= 1.4.0+git20110226), libsl0-heimdal (>= 1.6~git20120311), libtinfo5, libwind0-heimdal (>= 1.4.0+git20110226)
Suggests: heimdal-docs, heimdal-kcm
Conflicts: ftp (<< 0.16-1), heimdal-servers (<< 0.4e-7), kerberos4kth-clients, kerberos4kth-user, netstd, openafs-client (<< 1.2.2-3), otp, rsh-client (<< 0.16.1-1), ssltelnet, telnet (<< 0.17-1), telnet-ssl (<< 0.14.9-2)

isn't even a very complex set of dependencies.

(It's also been observed elsewhere that this isn't, perhaps, the vast comedy of metadata errors one might have supposed existed.)

[sarbian]

And yes, the CKAN issues can be buried by kookery, just like all issues and valuable discussion. There was a good group of issues from way back of CKAN not installing MFI, then installing a version of MFI that caused problems with Deadly Reentry, which probably also involved issues being reported to that thread. Also, let me remind you: CKAN is a machine. It does the exact same thing every time. This affected everyone that used CKAN and FAR, not just the ones that reported it.

To be fair the MFI problem was on our/my side. MFI code was updated without changing the version in the source and my server built a zip with the same name+version.

[nobodyhasthis]

That's a complete non-sequitur, in no way addressing the point

Yes indeed. It is actually miss direction. No offense intended. I just used a bit of cognitive dissonance to break things up a bit. Stops people getting stuck with the original metadata excuse too much. The point was to justify that mods sometimes can't use CKAN with without a user input choice. This can be a temporary problem which needs a override choice. A choice which we can't yet make.

To be fair the MFI problem was on our/my side. MFI code was updated without changing the version in the source and my server built a zip with the same name+version.

Hey so it goes. We all learned something. Any mod creation comes through the hard work of very generous people. The fact we get any thing at all is amazing. You guys are all great at what you do.

The whole point of my original post was in response to people still arguing that metadata is everything. It might be 99% of the time. However manual user driven CKAN installs are still required. For various reasons because mistakes can happen. Squad can also easily bring the whole house of cards down with KSP hot fixes. The mod CKAN comparability decision should be a suggestion not an absolute unbreakable law. It should let you install incompatible mods at your own risk. As suggested there is also some really good reasons why this is a bad decision. Logs need to record when it happens to stop people calling foul when the game breaks.

Edited July 1, 2015 by nobodyhasthis

[damerell]

The point was to justify that mods sometimes can't use CKAN with without a user input choice. This can be a temporary problem which needs a override choice. A choice which we can't yet make.

You can install a specific version of a mod via the CLI.

The whole point of my original post was in response to people still arguing that metadata is everything.

Has anyone? As far as I can tell, everyone would like it to be correct, much as there's been an argument about some other problems. "Metadata should be correct" seems to be an utterly uncontroversial statement.

The mod CKAN comparability decision should be a suggestion not an absolute unbreakable law. It should let you install incompatible mods at your own risk.

I think it would be doing modders an enormous disservice for CKAN to provide an easy way to install mods believed to be incompatible, completely at odds with the way that it can be an asset for modders as well as users if it consistently provides correct mod installs. Squad put out 1.0.5? You're no worse off than you were before CKAN existed; but now you have the option of testing mods and getting their metadata fixed. That's exactly what I'm going to do when I finish my current expedition in 1.0.2 - if Murdabenne hasn't done the lot.

[ferram4]

The most obvious solution from my perspective would be for the mod author to work with the CKAN people so that it installs the mod correctly, thus eliminating all CKAN-related inquiries from people having problems because they installed the mod with CKAN. As far as what "work with" looks like, from what I can tell, all it entails is simply saying "go for it". Nevermind that things have been done without permission already anyway and the request for permission seems to be an inconsistent policy. Who cares? If this whole thing can be resolved by saying "go for it" then why not do exactly that?

Well, for one, there's the principle of the thing: I'm not giving permission after CKAN contributors have shown that they don't consider permission necessary. For two, I want a permanent solution; I don't want a "and now it shows up 6 months later as a problem again" solution, because that's what's going on right now. I don't want to have to chase after CKAN to get them to stop screwing me over, but ultimately that's what this ends up being. I don't appreciate any idea that's going to result in me having to help the people that decided to screw me over after they decided that what I wanted didn't matter.

(It's also been observed elsewhere that this isn't, perhaps, the vast comedy of metadata errors one might have supposed existed.)

Dunno, that's pretty damning. After all, for all those issues, none of them have affected anyone who bothered with manual installs; a good metric for this should be the number of errors multiplied by the number of CKAN users that installed FAR, and that's gonna be way above the people who installed it manually bad enough that InstallChecker couldn't figure out how things broke. Seriously, from my perspective, you're doing a lot worse than winzip.

[nobodyhasthis]

Squad put out 1.0.5? You're no worse off than you were before CKAN existed; but now you have the option of testing mods and getting their metadata fixed. That's exactly what I'm going to do when I finish my current expedition in 1.0.2 - if Murdabenne hasn't done the lot.

Yes, no worse off that before CKAN existed. Also no better off with CKAN last week because it would not work without the new metadata. Glad you agree it used to break then. Well hopefully not now. When 1.0.5 hits the new version checking ideas in the development notes should kick it. Using the suggested "fuzzy"-version check. Also Murdabenne has gone a bit further that just fixing metadata. His suggestion for forced updates can bypass the need for chasing metadata on a temporary basis. On the other hand as you and others have stated it might make things worst. The jury is still out on this one. Either way is a tough choice. See https://github.com/KSP-CKAN/CKAN/issues/1173 Edited July 2, 2015 by nobodyhasthis

[ironclad]

When I installed CKAN, I already had a few mods in my gamedata folder. These were autodetected by CKAN. How do I transform these to proper ckan-managed mods? The mods in question are modulemanager, remotetech, waypoint manager, kerbal alarm clock, comcat mission menu.

Deleting the folders and forcing a check crashes ckan.