Update Pleroma references in documentation #36
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
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: AkkomaGang/akkoma#36
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?
Many of the install guides still refer to the Pleroma repo and the like.
To-do:
installationdirectoryOne thing I'm wondering is that there's refences to Pleroma's IRC channel for support. What's the best way to handle this sort of thing?
Also should the sample config files be updated as well?
we don't really have any sort of irc support, so i guess for now it can just be cut out?
by sample config? if it links to the git repo just for reference then i guess we redirect them here, but there are some references to repos actually needed (like emoji stuff) which isn't migrated here yet
I was wondering if it's okay to change the
pleromauser toakkomain the docs or should that be kept as is?should akkoma's docs even reference pleroma-fe? from what I understand one of the main points of this fork is to make any frontend able to be the "main one" (which is also why I don't think our pleroma-fe should be rebranded to akkoma-fe)
imo the extensive docs should be removed and replaced with a link to docs-develop, with a reference to akkoma's soft fork of pleroma-fe as well.
yeah, when i fully disconnect pleroma-fe (coming soon (tm)) it'll probably be a good idea to remove the links from the docs, but until then i guess they'll stay
Hi, I'm not sure if this belongs here or to a separate ticket, but there are also a lot of references to Pleroma in environment variables, PostgreSQL user, etc. For example, my instance wouldn't start until I symlinked
/etc/akkomato/etc/pleromaas it would otherwise complain about missingPLEROMA_CONFIG_PATH.I think I could take a shot at this, but what is your stance on what pleromas should be changed to akkomas?
this would break a lot of existing installations and renaming every folder and user is a hassle, so unless you could write a script that automates it i think it should be at at least kept as a fallback
@mjmrotek does this fix the issue for you?
271e08fa48Perhaps I could make the changes to
lib/pleroma/config/release_runtime_provider.exin #48 be a separate PR.Ok, it's just that some instructions from https://docs.akkoma.dev/main/backend/installation/otp_en/ don't work because of things named "akkoma" in the docs and "pleroma" in the actual downloaded files, for example
/opt/akkoma/installation/akkoma.nginxis actually/opt/akkoma/installation/pleroma.nginx, same for/opt/akkoma/installation/init.d/akkoma.Thanks, I'll try. The symlink hack worked for me though, so it wasn't a pressing issue, just something that confused me during installation. I also had a leftover Pleroma files on the same server, so initially Akkoma worked but was reading the Pleroma config while I didn't notice.
Should be fixed in #48 which was merged just now.
I think the only hardcoded path in the actual Pleroma code that needed to be changed was in
lib/pleroma/config/release_runtime_provider.exwhich was fixed in #51 (with a fallback to the old path).@floatingghost @sfr okay to close now?
seems good to me, thanks for all the work, it helps a lot