Package Details: thedarkmod-bin 2.07-1

Git Clone URL: https://aur.archlinux.org/thedarkmod-bin.git (read-only, click to copy)
Package Base: thedarkmod-bin
Description: First person stealth game
Upstream URL: https://www.thedarkmod.com/main/
Licenses: GPL, GPL3, BSD, CCPL, boost, custom:curl
Conflicts: thedarkmod
Provides: thedarkmod
Submitter: diabonas
Maintainer: diabonas
Last Packager: diabonas
Votes: 22
Popularity: 0.032180
First Submitted: 2019-11-24 17:04
Last Updated: 2020-03-02 14:44

Required by (0)

Sources (65)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

es20490446e commented on 2019-11-26 01:09

I get that the conflict in the package "thedarkmod" is that, being the name the official one, it shall only contain official assets.

On the other hand reading https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_submission:

  • "The submitted PKGBUILDs must not build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in comparison to the official ones."

And seeing that such alternative packages are common in the AUR, for example:

  • ttf-google-fonts-git

  • ttf-google-fonts-opinionated-git: with updated version of some fonts

  • ttf-google-fonts-typewolf: selection of the above fonts

I understand that it's perfectly possible to provide an alternative version of the package as long as it suggest it's a modified one, and provides valuable alternative functionalities.

So I'm providing an alternative version for this package, called "the-darkmod-tweaked", with the following enhancements over the official bundle:

  • Separated saved games and downloaded mission repository for each user.
  • Missions cache auto-cleanup.
  • Enhanced installation speed compared with the official installer.

es20490446e commented on 2019-11-25 22:08

My suggestion is very simple: recognize that good enough working software today is always more desirable than a perfect one that will never come.

diabonas commented on 2019-11-25 20:25

Like I said, feel free to

  • either provide a clear and well-written wrapper that runs the game from a user directory (as you are well aware, the current state of your software was rejected not only by the Arch Linux community, but also by an upstream The Dark Mod developer), or
  • even better, work directly with upstream to resolve the long-standing bug to be able to run the game from a read-only base directory.

I feel like this conversation is going in circles, please refrain from posting further comments unless they contain concrete, actionable suggestions or actual bug reports, I am going to ignore everything else from your side.

es20490446e commented on 2019-11-25 19:50

That would be a good idea, except because that cannot be accomplished.

The game can only write in its folder, and the Linux file system doesn't differentiate between write permissions and remove permissions for a folder.

So you have either to choose between the folder being editable and removable to any user, or nobody being able to use it and having the game broken.

That will naturally lead to you using my program or a clone, or keeping a broken package.

diabonas commented on 2019-11-25 17:59

Patches to improve the package are always welcome! I have yet to come across a suggestion from you that respects the packaging guidelines, which I would be happy to incorporate into the package. I feel like this would be a more constructive investment of everyone's time, including yours.

es20490446e commented on 2019-11-25 12:11

This package is now vulnerable. It requires users to manually be added to the "game" group for the application to work, and then any of those users would be able to delete the game folder manually.

Currently I have a healthy relationship the Manjaro community, or any other person in the world. As example they just implemented my suggestion of not compressing packages on Pamac, so AUR updates are the fastest.

Meanwhile none of my suggestions was ever considered, not even discussed, in Arch. Instead users like me frequently receive some incredibly arrogant response on why they are clueless.

But even worse that attitude is encouraged, and the perpetrator always finish being applauded. This is not acceptable, and while this happens I'm being unable recommend Arch as platform because of the bully group temper.

ainola commented on 2019-11-25 02:19

Alberto, I can only see one comment that was overtly aggressive, and that was not from a TU. The rest have been courteous - This dynamic resembles a worker in retail having to deal with a belligerent customer. To twist this as some sort of conspiracy wherein this community of volunteers engages users with motivations of schadenfreude does nothing but throw gasoline on this tire fire.

As stated many times before, you are welcome to work on your own packaging methods but this work is not welcome on the AUR where standards are upheld by the individuals whom you now label as having "disgusting" behavior now that it's clear to you that you will not get your way. And I can say, such talk is not helping your case for account retention. :)

Have a great rest of your weekend; I hope that you think long and hard about how you want to interact with communities. Considering similar situations have occurred with Ubuntu and Manjaro, perhaps it's time to look inward to see what's going wrong.

es20490446e commented on 2019-11-25 01:55

https://youtu.be/LaSzRlUgnf0

eschwartz commented on 2019-11-24 23:49

Furthermore you enforced it by force.

Moderation does tend to be by force, so this is a true statement.

es20490446e commented on 2019-11-24 23:27

Those tweaks are non obvious and surprising, there's no reason to have them, and the bug report you expect to be fixed for this package to work dates back to 2013.

Your view doesn't fit the real situation. Furthermore you enforced it by force.