Add s6 overlay for auto discovery

[Zen3515]

This PR enables the auto-discovery of cups printer via dnsmasq.
This PR will fix #9.

Here is the list of changes.

• Switch to s6-overlay to manage process.
• Add four processes. cupsd, dbus, avahi-daemon, cups-browsed. Together, they enable the auto discovery function.
• Update readme to recommend changing docker hostname

I've tested with Windows, Linux, and Android. The printer automatically shows up.
If you didn't set the hostname the discovered printer will change name every time the container is recreated. That's why I update the readme too.

Please note that I tested with macvlan docker network. I find it to be the easiest way when you want to deploy many services that require broadcasting to work.

[Zen3515]

As an updated

• I've tested and found problem when restarting the container, the pid file for avahi-daemon is already exist, I've already implemented a fix
• I've also included a way to build with multiple architecture without the need to update github action, it should just work.

Please note that I tested by building the image with docker buildx and buildkit. I found that arch arm/v7 will be named as arm in TARGETARCH variable, which is not consistent with the doc, however, I add the check condition for both, just in case.

I think this PR is ready for merging.
if you need anything, do not hesitate to let me know.

[leleobhz]

@Zen3515 hello!

Trigger: Community arguing here

I truly understand reasons this PR may exists and for typical all-in-one solution this maybe the best scenario, but I don't think this as the standard image, but needs to be a variant one. I'll not enter s6 arguing about one process per container and the reason for this concerns people that uses cups standalone, integrated over other applications (Eg. Samba) or use this image base for building containers that depends on CUPS. Another Containerfile (Eg. Containerfile.aio) and another variant (Eg: anujdatar/cups-docker:aio-latest) may be a way to attend both user cases.

My version on #7 is targeted to run into a Rpi 1 with 512mb/ram - and fits well the way it was now. Some even smaller solutions (Like embed a Zero W inside printer) may benefit from AIO as I don't. Keep both I think is the best to do.

That said, I liked this PR and I think it's possible to allow user choose best implementation based on what it needs. And that said, we need just wait to see mantainer point of view too.

[Zen3515]

@Zen3515 hello!

Trigger: Community arguing here

I truly understand reasons this PR may exists and for typical all-in-one solution this maybe the best scenario, but I don't think this as the standard image, but needs to be a variant one. I'll not enter s6 arguing about one process per container and the reason for this concerns people that uses cups standalone, integrated over other applications (Eg. Samba) or use this image base for building containers that depends on CUPS. Another Containerfile (Eg. Containerfile.aio) and another variant (Eg: anujdatar/cups-docker:aio-latest) may be a way to attend both user cases.

My version on #7 is targeted to run into a Rpi 1 with 512mb/ram - and fits well the way it was now. Some even smaller solutions (Like embed a Zero W inside printer) may benefit from AIO as I don't. Keep both I think is the best to do.

That said, I liked this PR and I think it's possible to allow user choose best implementation based on what it needs. And that said, we need just wait to see mantainer point of view too.

Hello,

I agree that users should have the option to choose whether to run all processes or not, based on their specific needs. I understand the importance of memory optimization, as I also prioritize efficiency when deploying applications on my rpi.

Regarding the tagging issue, I'm fine with either choice, but it should be clearly documented. I suggest letting the maintainer decide on the preferred route.

I also attached docker stats for consideration. I'm unsure of the pre s6-overlay memory usage, but here is the current stats in my homelab.

[ncovercash]

If we think it should be a variant, any chances you'd be willing to package/publish your fork? @Zen3515