Regarding permissions of directories/files

finicky936 · 2020-06-14 21:25:47

Hello,

I've recently put up my very first PKGBUILD I made on the AUR, it's basically a sandbox-like 2D game within a directory ( /opt ) which needs to have permissions since it works by allowing users to add or remove (as well as write) things from all directories/files within itself.

So far I've gotten to a specific point, but I am not sure at all how to handle this with permissions. Having permissions 777 is out of the question and I'm not too sure about using groups (i.e. if user should add themselves to the `games` group in order to do anything under the directory). should I maybe change the directory in which the package is installed as well?

Here's my PKGBUILD: AUR

also note, I did not make this game. In addition, i accept any criticism regarding how the PKGBUILD itself is written.

Sorry if I'm in the wrong section, this is my very first post and it is also my first time dealing with PKGBUILDs/git in general, so I'm pretty n00bish.

Lone_Wolf · 2020-06-15 10:48:11

Packaging software using Go is not easy, I suggest you check https://wiki.archlinux.org/index.php/Go … guidelines

Trilby · 2020-06-15 12:35:08

I'd not bother with their build script. Read what it does - it's pretty pointless. Upstreams .Command script is even worse. Just use `go` to build the source yourself, and install the resulting binary and other needed resources wherever they need to go. As is, you use the upstream build scripts, then have countless lines in the PKGBUILD re-arranging or just deleting things that should not have been installed. So just calling `go build` yourself would be much easier.

As for the needing write access, what is written to? The 'data' directory? I see a lot of resources read from there, but have not yet seen what is being written to. Looking at the source code, it'd be relatively easy to patch the source to use a better data directory (like /usr/share/<program>/) instead of one relative to the current working directory.

WorMzy · 2020-06-15 12:44:18

From what you describe, this isn't designed to be installed to system directories, but rather to a user home directory. If that is the case, then creating a package for it may not be feasible. There are ways of packaging such software (see [community]/dwarffortress) which make use of wrapper scripts to recreate the expected directory structure under each user's home directory, but this requires a lot more effort on your part as a packager. A better solution may be to work with upstream to make the application more multi-user system friendly.

finicky936 · 2020-06-15 13:46:25

Lone_Wolf wrote:

Packaging software using Go is not easy, I suggest you check https://wiki.archlinux.org/index.php/Go … guidelines

I see. In that case, perhaps using git to build software written in Go may not be the best idea for me.

Trilby wrote:

I'd not bother with their build script. Read what it does - it's pretty pointless. Upstreams .Command script is even worse. Just use `go` to build the source yourself, and install the resulting binary and other needed resources wherever they need to go. As is, you use the upstream build scripts, then have countless lines in the PKGBUILD re-arranging or just deleting things that should not have been installed. So just calling `go build` yourself would be much easier.
As for the needing write access, what is written to? The 'data' directory? I see a lot of resources read from there, but have not yet seen what is being written to. Looking at the source code, it'd be relatively easy to patch the source to use a better data directory (like /usr/share/<program>/) instead of one relative to the current working directory.

Yes, I do put a lot of lines within the PKGBUILD. Building everything via actually using go instead of using a script would be better, though rather harder I suppose.

As for needing write or read access, well, it's.. pretty much for everything under the application's directories and files itself. All the directories of the application: `data`, `script`, etc. all are customizeable and the user may read or write to them and to their files/dirs, and for folders like `chars` or `stages` the user may also add or remove directories/files. In addition, a `save` directory is created every time the user starts the game, but since there is no access, the application is unable to start since it cannot create the `save` directory. I assume this kind of setup would be better suited for writing under something like the $HOME directory, which is probably not a good idea for PKGBUILDs.

I may consider using the /usr/share/<program> directory in this case, I was only using /opt because I'm assuming it's a "contained" application and everything has to be together, but I think it's still better suited for $HOME directories.

WorMzy wrote:

From what you describe, this isn't designed to be installed to system directories, but rather to a user home directory. If that is the case, then creating a package for it may not be feasible. There are ways of packaging such software (see [community]/dwarffortress) which make use of wrapper scripts to recreate the expected directory structure under each user's home directory, but this requires a lot more effort on your part as a packager. A better solution may be to work with upstream to make the application more multi-user system friendly.

True, I did initially ignore the thought. Is it generally a bad idea to create PKGBUILDs for software that work better by being under the $HOME directory? Would it work better if the software installed itself under the $HOME directory, rather than the PKGBUILD doing so?

I would go for the wrapper scripts, looking at what community/dwarffortress does, it seems like it's checking if specific directories exist under $HOME/<.pkgname>/, and if those don't exist, it creates them, right? I can also try doing that. And until then I could also try communicating with upstream to see if it'd be possible to make it more multi-user system friendly.

So in general, package creation with Go is not an easy task, right? I completely forgot to post the -bin variation of the package I had created. All it does is directly take the pre-compiled binaries combined with the required resources, and extracts them, but I do unfortunately still run into the permissions issues. Maybe I could try utilizing wrapper scripts to install under $HOME for this package, for now?

Trilby · 2020-06-15 14:50:21

finicky936 wrote:

So in general, package creation with Go is not an easy task, right?

I disagree. Go's build system works quite well and readily respects many packaging standards when used correctly. It is no harder to package for go than for any other language. If someone writes code in C and instead of providing a standards-conforming makefile (or autotools scripts) they instead provide a home-made error-prone "build.sh" that often results in an unpackageable mess. Just the same with go. Go is not the issue with this upstream source - the problem is 1) their home-made and error-prone build script, and 2) the use of relative directories for program resources with no mechanism to customize the location. Both of these are common errors among novice programmers in every language, C most definitely included.

finicky936 wrote:

Maybe I could try utilizing wrapper scripts to install under $HOME for this package, for now?

You can install it under $HOME on your system, and you could post a thread (maybe under Community Contributions) with instructions or a script to help other people do the same. But you cannot package anything under $HOME.

finicky936 · 2020-06-15 16:54:34

Trilby wrote:

I disagree. Go's build system works quite well and readily respects many packaging standards when used correctly. It is no harder to package for go than for any other language. If someone writes code in C and instead of providing a standards-conforming makefile (or autotools scripts) they instead provide a home-made error-prone "build.sh" that often results in an unpackageable mess. Just the same with go. Go is not the issue with this upstream source - the problem is 1) their home-made and error-prone build script, and 2) the use of relative directories for program resources with no mechanism to customize the location. Both of these are common errors among novice programmers in every language, C most definitely included.
You can install it under $HOME on your system, and you could post a thread (maybe under Community Contributions) with instructions or a script to help other people do the same. But you cannot package anything under $HOME.

It should've been more appropriate for me to say that I'm not familiar with Go.
I will try to modify the git PKGBUILD accordingly, and scrap utilizing build.sh . I'll see how far I can get Go to work within the build() function as well as reducing unnecessary lines.

But to clarify a question I had, is it a different thing when the software itself creates the necessary directories i.e. by compiling the program via the build() function and, for instance, utilizing a makefile/giving flags to a makefile, or is it the same as when the PKGBUILD creates those directories via a script or within itself? Sorry if it sounds like a n00bish question, thanks so far for all the help.

eschwartz · 2020-06-15 17:28:48

finicky936 wrote:

As for needing write or read access, well, it's.. pretty much for everything under the application's directories and files itself. All the directories of the application: `data`, `script`, etc. all are customizeable and the user may read or write to them and to their files/dirs, and for folders like `chars` or `stages` the user may also add or remove directories/files. In addition, a `save` directory is created every time the user starts the game[...]

None of this is at all relevant. Unless the program itself writes to them, it doesn't need to be user writable. So the only relevant thing here is the "save" directory. Properly written applications (multi-user support) will not store this relative to the application itself (unless built/started in "portable mode"), but instead use https://wiki.archlinux.org/index.php/XD … irectories

If the data/script directories are customizeable, usually this should be accomplished by allowing files in XDG_DATA_HOME to override the ones in /usr/share or wherever. But I'd ask what's the difference between this and "edit the source code".

Some programs have a plugin framework for this...

Trilby · 2020-06-15 22:17:08

From what I gathered from an admittedly breif look at the source code, the data directory does seem to be hard coded. But it is hard coded in well organized data structure, so it should be pretty straight forward to write a simple patch for it - if not to get customizable or environment-variable respecting paths, at least to get a better hardcoded path.

Arch Linux

#1 2020-06-14 21:25:47

Regarding permissions of directories/files

#2 2020-06-15 10:48:11

Re: Regarding permissions of directories/files

#3 2020-06-15 12:35:08

Re: Regarding permissions of directories/files

#4 2020-06-15 12:44:18

Re: Regarding permissions of directories/files

#5 2020-06-15 13:46:25

Re: Regarding permissions of directories/files

#6 2020-06-15 14:50:21

Re: Regarding permissions of directories/files

#7 2020-06-15 16:54:34

Re: Regarding permissions of directories/files

#8 2020-06-15 17:28:48

Re: Regarding permissions of directories/files

#9 2020-06-15 22:17:08

Re: Regarding permissions of directories/files

Board footer