Config option for custom directory

[MTecknology]

It's possible to use a GITEA_CUSTOM environment variable to define where the custom/ directory is located, but managing an environment variable to run a daemon. It would be nice if this could also be a run-time and configuration option.

[mckaygerhard]

i want this feature/need too and this doe snot repect the unix standar layout for installing property...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[mckaygerhard]

this iisue was solved? why marked stalled?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[zeripath]

OK, I think just adding a --custom-dir="" option to the commands isn't really worth it. Especially as the cheapest way to implement that would be just to do os.Setenv("GITEA_CUSTOM", providedCustomDir).

We need to look again what $GITEA_CUSTOM really represents. It provides the basis of the following paths: (I will use $GITEA_CUSTOM for setting.CustomPath here)

• $GITEA_CUSTOM/options the base directory of local "gitignore", "license", "readme", "label" files.
• $GITEA_CUSTOM/public a directory of custom public assets
• $GITEA_CUSTOM/templates a directory of custom templates
• $GITEA_CUSTOM/robots.txt the robots.txt
• $GITEA_CUSTOM/conf/app.ini the default location of the app.ini <- the only separately configurable one of these

Is it acceptable for all of these things to be under say /etc/gitea/? (with the exception of app.ini being maybe pointed to /etc/gitea.ini)

What I suspect is really wanted to provide a build option that would change the default of $GITEA_CUSTOM and app.ini then you don't need this new option or -c making /usr/bin/gitea just work - however, in terms of the necessity of providing this, would it be possible to explain why you can't just make the gitea binary be shadowed by a sh script that adjusts the environment like many programs which don't necessarily obey the FHS e.g. Firefox or chrome? So the original gitea binary ends up as /usr/lib/gitea/bin/gitea and the shell script is /usr/bin/gitea with it setting the GITEA_CUSTOM and passing -c as appropriate.

[mckaygerhard]

El sáb., 13 de abr. de 2019 a la(s) 13:31, zeripath ( notifications@github.com) escribió:

What I suspect is really wanted to provide a build option that would change the default of $GITEA_CUSTOM and app.ini then you don't need this new optionor -c making /usr/bin/gitea just work - however, in terms of the necessity of providing this, would it be possible to explain why you can't just make the gitea binary be shadowed by a sh script that adjusts the environment like many programs which don't necessarily obey the FHS e.g. Firefox or chrome? So the original gitea binary ends up as /usr/lib/gitea/bin/gitea and the shell script is /usr/bin/gitea with it setting the GITEA_CUSTOM and passing -c as appropriate.

That its the idea! thanks for your explanation! as i always said why not center effors to real needs like this?

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2228 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAL7XDGGYCZZKNZGFBXEZODPQIKFRANCNFSM4DU6FVWQ> .

[zeripath]

But why can't you use a script to shadow the Gitea binary like is done for Firefox or Chrome?

[mckaygerhard]

1. distributions does not use those horrendous scripts.. set right paths in filesystems
2. it's not stanar, firefox and chrome does are not installed on that way in debian systems.. by example
3. a script produces issues due confuses gitea paths

simple! reasons!