Package Details: ckan 1.34.4-1

Git Clone URL: https://aur.archlinux.org/ckan.git (read-only, click to copy)
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
Submitter: birdspider
Maintainer: Khorne (politas)
Last Packager: Khorne
Votes: 30
Popularity: 0.44
First Submitted: 2014-12-30 19:22 (UTC)
Last Updated: 2024-01-24 08:48 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

azymohliad commented on 2018-02-11 02:57 (UTC) (edited on 2018-02-12 03:28 (UTC) by azymohliad)

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 (UTC)

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 (UTC)

@spacekookie

Would you recommend installing this today or using yours instead?

birdspider commented on 2017-07-07 10:13 (UTC) (edited on 2017-07-07 10:14 (UTC) by birdspider)

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

spacekookie commented on 2017-07-06 16:08 (UTC)

@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 (UTC)

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

spacekookie commented on 2017-06-04 19:55 (UTC)

@birdspider 1) Why doesn't ckan enable systemd-binfmt if it's required 2) Why would ANYONE in their right mind enable a Linux to execute random windows binary files? 3) I can complain about the application not being launch-able from the terminal if that is the only way the package makes it possible to launch and at the same time want a desktop file But I guess you're unwilling to change the package. I made my own locally and I guess I'll keep it up to date for myself as well. If anyone else is interested: https://github.com/spacekookie/stuff/tree/mistress/ckan

birdspider commented on 2017-06-04 17:20 (UTC) (edited on 2017-06-04 17:20 (UTC) by birdspider)

@spacekookie: it does not fail on my PC; do you have systemd-binfmt.service enabled ? Also as per https://wiki.archlinux.org/index.php/Arch_packaging_standards#Directories /opt is for 'Large self-contained packages'. Ckan is neither large nor self-contained (mono). Why do you care for a .desktop file when your origninal issue was not beeing able to start it from terminal ?

spacekookie commented on 2017-06-04 16:02 (UTC)

@birdspider Well it means that when you run "ckan" from a terminal it fails with "The file '/usr/bin/ckan' is marked as an executable but could not be run by the operating system." Placing a script at /usr/bin/ckan that calls "mono /opt/ckan/ckan.exe" makes that a lot nicer. My PKGBUILD also creates a desktop file in /usr/share/applications/

« First ‹ Previous 1 2 3 4 5 Next › Last »