Package Details: ckan 1.25.1-1

Git Clone URL: https://aur.archlinux.org/ckan.git (read-only)
Package Base: ckan
Description: All you need to find, install, and manage mods for Kerbal Space Program (ksp)
Upstream URL: https://github.com/KSP-CKAN/CKAN/
Keywords: game kerbal ksp manager mod
Licenses: MIT
Conflicts: ckan-git
Submitter: birdspider
Maintainer: adam900710
Last Packager: adam900710
Votes: 22
Popularity: 0.188488
First Submitted: 2014-12-30 19:22
Last Updated: 2018-07-11 13:52

Latest Comments

cousinm commented on 2018-07-13 10:30

Hi

I add to replace

ar xv ../${pkgname}-${pkgver}.deb

with

ar xv ${pkgname}-${pkgver}.deb

to make this work. I don't know if this is an error in the package or something wrong in my environment...

adam900710 commented on 2018-07-11 13:55

Updated to 1.25.1, extracted from .deb package, so we now have man page, correct mono wrapper, icon, .desktop file, changelog.

spacekookie commented on 2018-05-31 09:51

Hey everyone,

I didn't realise I was the only maintainer to this project now. I'll update the package and give it some love next week when I finish travelling.

politas commented on 2018-03-20 00:14

Hi, politas here from the upstream project. It's great to see someone taking on the job of making KSP-CKAN work properly on Arch; it's always been a problematic platform for us. Just to let you know, v1.22.6 has been completely broken by changes on GitHub. All users should upgrade to v1.24.0 (Which has a lot of improvements!) I think we'll be bringing out v1.25.0 soon, which will be adding support for the Making History DLC.

If there are any changes we could make in the upstream that would make things easier for Arch packaging, please let us know!

azymohliad commented on 2018-02-11 02:57

Btw, I would agree with @spacekookie in most of her points. Having small wrapper looks better to me than relying on another systemd service. Also, it would be really nice to have .desktop file (come on, it's GUI app). However, I agree with @birdspider about /opt. Overall, I think Debian's package's structure is optimal and using it will keep PKGBUILD small.

@birdspider, would you be interested to make use of it? If you are busy I can make a PKGBUILD, then you can edit whatever you wouldn't like. I'm equally happy with @spacekookie's PKGBUILD, so if any of you could merge it - it would also be great (although I vote for not using /opt).

UPD: Here is my modified PKGBUILD based on .deb: http://txt.do/dhhdq Maybe /usr/doc should be removed from there, I'm not sure.

azymohliad commented on 2018-02-11 02:07

The latest release (pre-release) on Github already has Debian package with .desktop file, icon, simple wrapper script in /usr/bin. I guess it could be used as a base for this package.

flavius717 commented on 2018-01-15 22:56

@spacekookie

Would you recommend installing this today or using yours instead?

birdspider commented on 2017-07-07 10:13

@spacekookie:

you are now a co-maintainer - feel free to change everything

spacekookie commented on 2017-07-06 16:08

@birdspider

Not that I have to care anymore but I would like to adress some of your comments :P

1) and 2) NO! systemd-binfmt isn't enabled by default, why would it? If you have something quirky on your system then maybe, yea. But don't make assumptions for every user. Especially because enabling it would go *hard* against Arch's core philosophy.

Now, here we're getting into an argument about how a package should behave because...yea, I don't want an AUR package to randomly enable services on my system. But PKGBUILD files are able to communicate to the user. And as such, if your package requires binfmt to be enabled, maybe you should do that. I mean, yea there are comments below to check but that's kinda stupid imho.

3) Addressing your third point...it's not possible to launch CKAN from the CLI if not having binfmt enabled (which I will do when hell freezes over) so the only other choices are a) a wrapper script or b) a .desktop integration file to start from my GUI. Neither is provided by this package. THAT's why I brought up the desktop file, as an alternative way of launching the application. Besides, shouldn't a GUI application provide one anyways just for good measure? It kinda sucks having to start GUIs through the terminal if you ask me.

Also my original point WAS about a wrapper script that removes the need to enable a shitty systemd service and I only later brought up the desktop file as a good measure for "btw, wouldn't it also be neat". But hey...whatever floats your boat.

birdspider commented on 2017-06-04 20:24

@spacekookie:

1) So you would like a package to mess with your systemd units ? I simply asked if you have it enabled. If I read it correctly core/systemd should have the systemd-binfmt.service enabled by default.

2) see 1) this is the default imho.

3) complain all you want, I just wanted to focus on the issue at hand (not launchable via cli) then you brought up the .desktop file. I inqired if your focus has changed to get it to run via .desktop or if the cli issue was still relevant.

All comments