Kovah / LinkAce

LinkAce is a self-hosted archive to collect links of your favorite websites.
https://www.linkace.org
GNU General Public License v3.0
2.5k stars 159 forks source link

Add support for Podman #779

Closed chrissawyerfan4 closed 2 months ago

chrissawyerfan4 commented 3 months ago

This commit:

I've tested it by using podman system reset which removes all containers and images and such, and then running the commands from the contributing docs in this commit's state, only replacing the word "docker" with "podman" for each command

If this all works well, eventually I think we can also update the documentation in the website repository to mention that Podman seems to work as a drop-in solution even if Docker remains the reference so long as that's what you're developing with. The vibe I get from Podman is that it's less commercial or more in the open source spirit than Docker, which might appeal to those self-hosting LinkAce, besides minor technical/architectural differences where someone might prefer one over the other

chrissawyerfan4 commented 3 months ago

Oops, I seem to have based this on the latest commit made in main rather than dev. (I made a new branch, reverted to a specified commit, so that this is not dependent on the changes I made for #776.) I guess that should be resolved, but GitHub likes to keep history even if you push -f so, while I can resolve it locally, I'm not sure if that would resolve it on GitHub. Probably I should rebase my commit on the dev branch's current head, right?

Kovah commented 2 months ago

That's a great fix, thank you very much! Didn't know that Podman needs the docker.io/library prefix for general containers.

Regarding the container name: I personally got rid of any container names for my projects as I find it easier to use docker compose exec [service name] (which I have a dce abbreviation for). I will update the dev docs to use that instead of docker exec instead.

chrissawyerfan4 commented 2 months ago

Didn't know that Podman needs the docker.io/library prefix for general containers.

I guess the idea is to be unbiased towards any vendor, but then it does ship with some aliases built-in it seems, so... :shrug: I'm just happy there is a syntax that works for both :)

I personally got rid of any container names for my projects [...]. I will update the dev docs to use that instead of docker exec instead.

Not sure if I enabled contributor edits for this pull request but, if I did, do you want to just get rid of that name line once the dev docs are updated and then hit merge?