Jump to content

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


pjf

Recommended Posts

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

Why change the spec version to 1? Isn't it an upwardly compatible spec? so that anything 1 will be supported by 1.4, etc?

Link to comment
Share on other sites

Why change the spec version to 1? Isn't it an upwardly compatible spec? so that anything 1 will be supported by 1.4, etc?

yes, but it is easier for us to detect what you do. If you use v1.4 we know that you'll use the "find" command, if you use v1.12 we know you want to install files into the VAB/SPH folder.

But you choose what to use

Link to comment
Share on other sites

You'll want to include an abstract for each of the configuration packages to explain what they do (and you can mention that they are optional, too, which is unusual for mod config packs so far)

Link to comment
Share on other sites

... The law of navigation is that the more maneuverable yields to the least maneuverable.

And we can all agree that KSP falls under Maritime Law. ;)

I love the ease of CKAN, and use it extensively. I also find myself maintaining oodles of mods the old fashioned way (one folder at a time).

Ferram's concerns and the resulting conversation is compelling, since it factors in thoughts I have about CKAN even as just an end-user. It's extremely powerful and sophisticated, but at the same time remarkably limiting; It's the combination of hands-off automation, and *additional* manual effort needed by users and maintainers that's contributing to the issues being described.

Splitting the rest of my gaming time with silly adventures like Skyrim, I've come across tools like Mod Organizer. The core functionality (and data model) is much different, but it's a true swiss army knife for managing any kind of user-contributed content/mods. The ability to install from within the "network" as well as manage purely local (manual) installs is terrific.

Does CKAN need to remain an all-or-nothing approach? Can its features extend to support local installs of stuff--with collision detection for mods that CKAN eventually picks up?

Link to comment
Share on other sites

Decided to switch over to Manjaro linux as it is easier to manage kernels. Question is how would i update the openssl library for Manjaro?

I am assuming that is the reason I am getting the following message on mono. BTW mono is ver 4.

Could not set X locale modifiers

1566 [1] ERROR CKAN.URLHandlers (null) - There was an error while registering the URL handler for ckan:// - Could not find a part of the path "/home/theersink/.local/share/applications/mimeapps.list".

1574 [1] ERROR CKAN.URLHandlers (null) - at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0

at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, System.String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) [0x00000] in <filename unknown>:0

at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int,System.IO.FileOptions,string,bool,bool,bool)

at System.IO.StreamWriter.CreateFile (System.String path, Boolean append, Boolean checkHost) [0x00000] in <filename unknown>:0

at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize, Boolean checkHost) [0x00000] in <filename unknown>:0

at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize) [0x00000] in <filename unknown>:0

at System.IO.StreamWriter..ctor (System.String path) [0x00000] in <filename unknown>:0

at (wrapper remoting-invoke-with-check) System.IO.StreamWriter:.ctor (string)

at System.IO.File.WriteAllLines (System.String path, System.String[] contents) [0x00000] in <filename unknown>:0

at CKAN.URLHandlers.RegisterURLHandler_Linux () [0x00000] in <filename unknown>:0

at CKAN.URLHandlers.RegisterURLHandler (CKAN.Configuration config, IUser user) [0x00000] in <filename unknown>:0

Link to comment
Share on other sites

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.

As I've already noted, dependency cross-upgrades are rare things.

Also, note that because of their limited subset they are much more limited in the problems they can cause.

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.

After much screaming, yes. This wasn't around the last time CKAN completely screwed me over, and was created partly in response to that. Problem though: this doesn't cover people who decide not to mention that they're using CKAN, and CKAN provides no way to identify those people.

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.)

Because that help is limited and doesn't provide me any recourse if they decide not to. The entire problem is that my support workload is dependent on CKAN's whims and competence; if they screw up or decide to not clean up their problems, I have no recourse.

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.

Yes, we're at an impasse, aren't we?

I gather the trouble with the incorrect ModuleFlightIntegrator version was caused by your inconsistent version numbering not alpha-sorting correctly.

No, actually. That issue was in the ModularFlightIntegrator metadata pointing to the wrong file, not the FAR metadata. I also have no idea why my version numbering is "inconsistent" or screws up CKAN; numbers increment, and there's a codename after an underscore. Very simple to parse by anyone, I can't imagine why CKAN doesn't work with it.

Of course not. Nothing is guaranteed to be perfect straight away.

Sure it is. I release an update, and guess what? A manual install following directions perfectly works straight away. It's only CKAN that seems to change that.

Especially since your antipathy towards CKAN means you aren't helping CKAN to handle FAR properly.

Welp, there it is. "We're causing problems for you? Too bad, why don't you put your effort into cleaning up our mess?"

All the problems that CKAN has with FAR are because of your failures, not mine. Installs and updates of FAR were fine until you came along, and now, every so often, CKAN causes problems.

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.

Forum rules only update under pressure from users, not modders. There is insufficient backlash against CKAN from users for that to be a viable course. They'd need to do something cartoonishly evil to get that to happen at this point.

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)

And this is the conclusion that I keep coming to, but I really dislike it. It unnecessarily punishes users that have avoided CKAN, and I would prefer consequences limited to those who deserve it, not extended to everyone.

Just a reminder for everyone, all I want is for CKAN to be as reliable as a perfect manual install, with CKAN and its contributors handling all of the work they've taken on for themselves, and the option to opt-out. That's all I want. I wish CKAN didn't exist, but I know it's not going anywhere, so all I want is a way out and for CKAN to clean up its own messes and not cause them in the first place. I want CKAN and its contributors to hold themselves to a higher standard than they currently do.

Link to comment
Share on other sites

Just a reminder for everyone, all I want is for CKAN to be as reliable as a perfect manual install, with CKAN and its contributors handling all of the work they've taken on for themselves, and the option to opt-out. That's all I want. I wish CKAN didn't exist, but I know it's not going anywhere, so all I want is a way out and for CKAN to clean up its own messes and not cause them in the first place. I want CKAN and its contributors to hold themselves to a higher standard than they currently do.

This is easy to do. Create an issue on the KSP-CKAN/NetKAN Github when you are releasing a new version asking for someone to check that CKAN is installing FAR correctly after the upgrade. That'll bring your update to the attention of the NetKAN maintainers, exactly the people who can test and sort out any issues.

Link to comment
Share on other sites

This is easy to do. Create an issue on the KSP-CKAN/NetKAN Github when you are releasing a new version asking for someone to check that CKAN is installing FAR correctly after the upgrade. That'll bring your update to the attention of the NetKAN maintainers, exactly the people who can test and sort out any issues.

The only problem with it is that our bot automatically adds the new update to CKAN. We can test if the new update works, but there can be a couple of users that can have problems.

Link to comment
Share on other sites

No, actually. That issue was in the ModularFlightIntegrator metadata pointing to the wrong file, not the FAR metadata. I also have no idea why my version numbering is "inconsistent" or screws up CKAN; numbers increment, and there's a codename after an underscore. Very simple to parse by anyone, I can't imagine why CKAN doesn't work with it.

This is your alpha-sorted list of versions:

FerramAerospaceResearch-1-v0.15.3.1.zip

FerramAerospaceResearch-1-v0.15.4.1_Goldstein.zip

FerramAerospaceResearch-1-v0.15.4_Glauert.zip

FerramAerospaceResearch-3-0.15.4.1.zip

FerramAerospaceResearch-3-0.15.5.1.zip

FerramAerospaceResearch-3-0.15.5.zip

FerramAerospaceResearch-v0.14.3.2.zip

FerramAerospaceResearch-v0.14.4.zip

FerramAerospaceResearch-v0.14.5.1.zip

FerramAerospaceResearch-v0.14.5.zip

FerramAerospaceResearch-v0.14.6.zip

FerramAerospaceResearch-v0.14.7.zip

FerramAerospaceResearch-v0.15.0_Euler.zip

FerramAerospaceResearch-v0.15.1_Fanno.zip

FerramAerospaceResearch-v0.15.2_Ferri.zip

FerramAerospaceResearch-v0.15.3.1.zip

FerramAerospaceResearch-v0.15.3_Froude.zip

EDIT: Sorry, those are the best job CKAN has been doing with the versions. Here's the actual zip file names you release, again alpha-sorted:

FAR_0_15_1_Fanno.zip

FAR_0_15_2_Ferri.zip

FAR_0_15_3_1_Garabedian.zip

FAR_0_15_3_Froude.zip

FAR_0_15_4_1_Goldstein.zip

FAR_0_15_4_Glauert.zip

FAR_0_15_5_1_Hayes.zip

FAR_0_15_5_Haack.zip

FAR_0_15_Euler.zip

FerramAerospaceResearch_v0_14_7.zip

And for ModularFlightIntegrator:

ModularFlightIntegrator-1.0

ModularFlightIntegrator-1.1.1

ModularFlightIntegrator-1.1

If you can't see why that is inconsistent, then I don't think you understand consistency from a computing perspective. Sometimes you've got two levels of numbers, sometimes three and sometimes four. As a result, they list in a wonky order every time you drop to an extra level.

- - - Updated - - -

The only problem with it is that our bot automatically adds the new update to CKAN. We can test if the new update works, but there can be a couple of users that can have problems.

I was going for the least effort from Ferram's perspective. Obviously, If he posted before releasing letting the NetKAN crew know the new zip contents, CKAN could be ready when it goes live.

- - - Updated - - -

Decided to switch over to Manjaro linux as it is easier to manage kernels. Question is how would i update the openssl library for Manjaro?

I am assuming that is the reason I am getting the following message on mono. BTW mono is ver 4.

Have you tried running this?

mozroots --import --ask-remove

That's what updates the certificate store and I believe it is common across all Linux distribs. I'm not sure what the name of the libcurl package is on Arch-based distribs. Does Manjaro use pacman? I found on this page the following comment:

Arch doesn't split things into dev packages, so all you need is curl to get libcurl.

And following that are instructions that may help you. If you report back the correct package name, that can be added to future release notes.

Edited by politas
FAR Github zip files compared to CKAN list.
Link to comment
Share on other sites

This is easy to do. Create an issue on the KSP-CKAN/NetKAN Github when you are releasing a new version asking for someone to check that CKAN is installing FAR correctly after the upgrade. That'll bring your update to the attention of the NetKAN maintainers, exactly the people who can test and sort out any issues.

"Hey, we're causing problems for you? Why don't you do the work of cleaning it up?" No, you decided to take over distribution, you handle the problems of it. You don't wanna even set up an automatic metadata check even though I outlined a way to do it... are you trying to cause problems?

EDIT: Sorry, those are the best job CKAN has been doing with the versions. Here's the actual zip file names you release, again alpha-sorted:

FAR_0_15_1_Fanno.zip

FAR_0_15_2_Ferri.zip

FAR_0_15_3_1_Garabedian.zip

FAR_0_15_3_Froude.zip

FAR_0_15_4_1_Goldstein.zip

FAR_0_15_4_Glauert.zip

FAR_0_15_5_1_Hayes.zip

FAR_0_15_5_Haack.zip

FAR_0_15_Euler.zip

FerramAerospaceResearch_v0_14_7.zip

And for ModularFlightIntegrator:

ModularFlightIntegrator-1.0

ModularFlightIntegrator-1.1.1

ModularFlightIntegrator-1.1

If you can't see why that is inconsistent, then I don't think you understand consistency from a computing perspective. Sometimes you've got two levels of numbers, sometimes three and sometimes four. As a result, they list in a wonky order every time you drop to an extra level.

No, I don't see why it's inconsistent; drop the naive sorting and take an equal number of levels and it all sorts itself perfectly. Like what humans do.

Also, ModularFlightIntegrator releases haven't been put together by me. They've been put together by Sarbian.

Also, this is not something unique to FAR, so if CKAN can't sort numbers like this, it's screwing up a lot more installs than you know.

I was going for the least effort from Ferram's perspective. Obviously, If he posted before releasing letting the NetKAN crew know the new zip contents, CKAN could be ready when it goes live.

...except the least effort from my perspective is that you show some professionalism and don't push metadata that hasn't been tested. CKAN has no error checking and apparently no desire to add it without drafting modders into fixing their errors for them.

And I still want the option to back out if you continue to cause problems.

Link to comment
Share on other sites

The problem was that it kept installing ModularFlightIntegrator 1.0, I added a min_version so it will install 1.1.1 now (when merged).

This was because sarbian kept it called 1.0 in the dll, that's why it wasn't noticeable when installing via CKAN.

Edited by Olympic1
Link to comment
Share on other sites

I was absent for quite a while from KSP (that stock heating bug killed my desire to play game until it is solved). Started to read all that flame.

A lot of described issues comes from misinformed users that everything is uninstalled perfectly while mod folder and some few files(mostly configs) in it remains.

Better, more visible warning to user and ability to delete folder after additional confirmation from user could solved a lot of issues. I suggested something like that several months ago, pointed by CKAN staff to opened Github thread about it in development, but it is aperantly not included yet in CKAN.

Small suggestion that should not be too hard to accomplish. Make additional list of mods for CKAN bot, to not upgrade (put new metadata file) problematic mods like FAR imediately. Instead, make a bot to send e-mail or other way of notification to human CKAN staff members, to check new version, test it and approve new metada for FAR mod.

I have take FAR for example, but there could be more mods that require special attention if bot is not capable for some simple(to human) tasks.

Link to comment
Share on other sites

"Hey, we're causing problems for you? Why don't you do the work of cleaning it up?"
Just asking for notification, nothing more. We'll do the work.
No, I don't see why it's inconsistent; drop the naive sorting and take an equal number of levels and it all sorts itself perfectly. Like what humans do.
I said "consistency from a computing perspective", not "consistency from a human perspective". But you're not exactly making things easy even for your non-CKAN users. This scheme you're using makes getting correct metadata significantly harder. You say we're causing problems for you? Well, you're causing problems for us, too.

And if this is the first you've heard of it then clearly, the CKAN contributors have been dealing with this CKAN problem without forcing you to clean it up.

Link to comment
Share on other sites

Have you tried running this?

Code:

mozroots --import --ask-remove

That's what updates the certificate store and I believe it is common across all Linux distribs. I'm not sure what the name of the libcurl package is on Arch-based distribs. Does Manjaro use pacman? I found on this page the following comment:

Arch doesn't split things into dev packages, so all you need is curl to get libcurl.

And following that are instructions that may help you. If you report back the correct package name, that can be added to future release notes.

Tried those, I got the same error.

Link to comment
Share on other sites

Just asking for notification, nothing more. We'll do the work.

You already have that. You know that bot you have that mindlessly updates metadata without checking to see if it's valid? Why not use that? You have notifications through that, an automated attempt at metadata, so the only thing left to do is to test it to see if it creates a proper install. Why isn't this already done?

I said "consistency from a computing perspective", not "consistency from a human perspective". But you're not exactly making things easy even for your non-CKAN users.

Yet they seem to have no problems at all. Only CKAN users seem to have problems.

This scheme you're using makes getting correct metadata significantly harder. You say we're causing problems for you? Well, you're causing problems for us, too.

And if this is the first you've heard of it then clearly, the CKAN contributors have been dealing with this CKAN problem without forcing you to clean it up.

Oh, no I knew that there was an issue, I just didn't think CKAN was being quite so stupid about it. Look, you guys decided to try and replace the manual download and install distribution method and in the process caused problems that never existed before. Your distribution problems shouldn't be my problems, you're the ones who decided to make this difficult. No one else has trouble sorting it, especially not on any of the hosting sites thanks to the fact that they're organized by release date and time.

No, you see, causing problems for you would be deliberately not including a version number, but even I'm not that much of an ass.

Link to comment
Share on other sites

So if someone wanted to theoretically port CKAN to a different game, what exactly would that entail? I recently started playing Rimworld again and saw a thread recommending someone port CKAN over to Rimworld. Figured I'd at least inquire to see how much work that would be. Unfortunately they don't seem to use websites with nice APIs for automatic checking of new releases, and there are numerous mods that conflict because they alter the same files. I fear they'd require breaking the cardinal rule of "don't overwrite someone else's files".

Link to comment
Share on other sites

So if someone wanted to theoretically port CKAN to a different game, what exactly would that entail? I recently started playing Rimworld again and saw a thread recommending someone port CKAN over to Rimworld. Figured I'd at least inquire to see how much work that would be. Unfortunately they don't seem to use websites with nice APIs for automatic checking of new releases, and there are numerous mods that conflict because they alter the same files. I fear they'd require breaking the cardinal rule of "don't overwrite someone else's files".

I'd think a far simpler tool like Nexus Mod Manager would be best in this situation. You can overwrite willy *AND* nilly. It's configurable for most any game that uses a mod folder structure. Games like Rimworld or Starbound have some fun mods, but the community & infrastructure are nowhere near big enough to support an entire network.

Link to comment
Share on other sites

Oh, no I knew that there was an issue, I just didn't think CKAN was being quite so stupid about it.
It's not. It figures out a lot of version number variation quite happily. Yours just happens to be weird in a way that no one predicted.
Link to comment
Share on other sites

Tried those, I got the same error.

I'll assume that you didn't get an error running the mozroots command.

Looking again at the output you got, I see that it says

[COLOR=#333333]Could not find a part of the path "/home/theersink/.local/share/applications/mimeapps.list"

Does that file exist in that location? This doesn't actually look like a certificates error at all, on close inspection. Where did you get your Mono package from?

Link to comment
Share on other sites

Ver 4 comes preloaded with manjaro. I did however copy the whole directory over from my Ubuntu. I bet it is still looking for that file structure. I think there are subtle differences.

Which directory, ~/.local?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...