[bug] Guide suggests installing frontend via source without sudo command #748
Labels
No labels
approved, awaiting change
bug
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs docs
needs tests
not a bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#748
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
At the end of the current install guide, under frontend installs, via source, the guide is currently missing
sudo -Hu akkoma
before the mix commands.Have you searched for this issue?
not an issue, these commands are common between install guides and some do not use sudo (Alpine uses doas)
it is an issue, as it installs the frontend under
root
, and chokes when the current directory is not/opt/akkoma
the rest of the install guide never mentions that the user needs to change their directory to
/opt/akkoma
, thesudo
-H
option does that implicitlywhy break consistency now?
as i say, these commands are not unique to this guide
they are shared across all guides - changing them here will break the alpine guide
which i think is rather worse than having a little inconsistency that any user that has any right to be hosting a fedi instance should be able to easily understand
why are the same commands linked across all of the guide variants like that? i can understand not wanting to break the commands themselves, but going out of the way to card consistency over platform quirks will not work here
at least add a
cd /opt/akkoma
command in front of it, even if it then installs it under root, it should then workwith the way it does, it guides the user to veer their car straight into a tree, off the road, which is an incredibly frustrating experience (as i have a friend who just did that, and got caught multiple times on the install guide telling them to do something that messed up their install, or just didnt work)
because, quite honestly, it's already a massive pain to keep documentation up to date
keeping documentation up-to-date across multiple very slight variants is even more work taking up even more time that i have vanishingly little of
what i'm saying is, i'm waiting patiently for your contribution
i'm at least noting the issue down, since i haven't seen it mentioned anywhere else
i'll poke some PRs once i have the energy to, but yeah
Would it be fine to just note how to run commands as root, akkoma and postgres once upfront and then e.g. prefix each command with
root#
,akkoma$
etc? This would allow duplicating even more stuff.Or will this be too confusing and end up with people copying the prefix into the terminal as well?
(Also, Debian ships
doas
and Alpine shipssudo
. Likely most distro offer both and only their default/recommended choice differs, meaning either variant may appear on any system. In practice though i’m guessing 90+% just use the default and those who don’t will know how to adapt things)It seems there’s (if the above suggestion or something similar works) even more parts we can dedupe. At first glance:
doas
/sudo
and the initial 3 user/group setup commandsMaybe we can move those three to “Prepare the system”?
except for
doas
/sudo
the only difference across Linux systems appears to be:systemd
oropenrc
We could either include all other parts individually in each guide, or if we move the install part out of it maybe even fully share this section with a variant selector for system service like we do for OTP vs Docker vs Source later for frontends?
*BSDs have a couple more differences due to
/usr/locale/
paths, different init systems each, etc; they might need to remain separateHaving pre-existing knowledge of what needs to happen works against me here in judging what’s the right level of verbosity and (de)duplication. If you could send patches to improve things it would be really great