Gitea tries to use /usr/bin as run dir

[Martmists-GH]

• Gitea version (or commit ref): Latest
• Git version: Latest
• Operating system: Arch Linux x64
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Description

I installed gitea from the repositories using pacman, but whatever I did it always seemed to use /usr/bin as working dir instead of /var/lib/gitea

[zeripath]

Unfortunately Gitea has non-fhs compliant expectations which mean that just building from source and placing the binary in /usr/bin will not work.

See "Changing the default CustomPath, CustomConf and AppWorkPath" in https://docs.gitea.io/en-us/install-from-source/ for how to set up the build environment to change the default locations so that Gitea will never look in the wrong place.

Or

Consider using the https://github.com/go-gitea/gitea/blob/master/contrib/fhs-compliant-script/gitea to shim the Gitea binary so that its environment is set up.

Or

Look at https://docs.gitea.io/en-us/specific-variables/ to see which environment variables you can set to tell Gitea to look elsewhere and/or https://docs.gitea.io/en-us/command-line/ to see the command line options.

Please could you advise your package maintainer change their package to use the LDFLAGS replacement trick described or the fhs compliant script in order to prevent further confusion.

Edit: the documentation is currently incorrect in calling this AppWorkDir it should be AppWorkPath.

[zeripath]

Hi @ArchangeGabriel @alucryd,

Looking at the arch Linux package information, I believe you are the maintainers of the Gitea package for arch Linux. If not I'm sorry for spamming you.

Gitea in its default build assumes that it is run from the root of its directory structure and doesn't comply with the FHS leading to confusion if the binary is placed in /usr/bin.

You can workaround this with using environment variables, or since 1.9 command line options but it's a little surprising for users that it doesn't work the way they expect.

Since 1.9, it's been possible to build Gitea in a way that means you can define these default directories within the binary file using an LDFLAGS at time of compile/link/make. We also now provide a FHS compliant script in contrib/ that you can use as /usr/bin/gitea whilst installing the Gitea binary as /usr/lib/gitea/gitea if you don't want to use that technique. (Please see the preceding comments for more information.)

Please could you update your package to use one of these techniques. Unfortunately we cannot change the default build of Gitea to be FHS compliant without breaking too many users, but I have tried hard to make it possible to build it in a compliant manner and/or be able to shim the binary so it appears compliant.

Thanks so much for continuing to package Gitea. Please do not hesitate to ask if you need further information.

[ArchangeGabriel]

@zeripath Thanks for pinging. So just to be sure, it means we should add -X \"code.gitea.io/gitea/modules/setting.AppWorkDir=/var/lib/gitea\" to our LDFLAGS, correct? Because I’ve just tried that and it did not worked (still telling /usr/bin as the default in gitea help).

[zeripath]

Damn! It should be AppWorkPath not dir. I'll send a PR to the docs to fix that sorry.

[ArchangeGabriel]

OK, that did it. ;) I’ve pushed the new package. :)

[zeripath]

Thanks @ArchangeGabriel sorry the documentation is incorrect.

In case you're interested the -X in the LDFLAGS simply changes the default value for the provided variable name.

In this case we do a delicate dance with this value, setting it when you set environment variables or command line options but if it remains empty then it is set in the end to the program location. By setting it with LDFLAGS you always ensure that it has a default value to fall back on.

Other go projects will likely be adjustable in similar ways even if their developers aren't aware of it.

Sorry once again that the documentation is incorrect.

[zeripath]

@Martmists I'm gonna close this bug as when you get the updated package it should be fixed.