Separate long dockerfiles into scripts

[yourjelly]

I think this change makes it easier to work with and it allowed me to see where the build was breaking when building with docker compose on unraid. The previous way didn't separate the actions out and did it as an opaque block.

[Josh5]

Give me a couple of days to figure this out. I like the work your doing for an Arch variant (I did it earlier on myself but go tired of maintaining it). What are you thinking the benefits of the Arch file system will be over Debian? I gave up because I could not really see any benefits, especially after SteamOS 3 came out with the Steam Deck.

Also, are you referring to buildkit? If so, you can disable it with export DOCKER_BUILDKIT=0

[yourjelly]

I like the work your doing for an Arch variant (I did it earlier on myself but go tired of maintaining it). What are you thinking the benefits of the Arch file system will be over Debian? I gave up because I could not really see any benefits, especially after SteamOS 3 came out with the Steam Deck.

The idea is to see if I can get the docker to run https://github.com/theVakhovskeIsTaken/holoiso which is basically the SteamOS 3 Deck build, headless. Fingers crossed, before making this pull req I was stuck getting read-only write permissions on installing Nvidia.

Also, are you referring to buildkit? If so, you can disable it with export DOCKER_BUILDKIT=0

I'm not sure what that is, I was using the docker compose plugin to run builds locally and in the window it builds this is how it looks when it runs scripts. (Specifically the light grey at the bottom.)

Before my changes it just ran a the whole RUN line strung together with the ( \ && ) without saying where it was failing. And made the process more difficult.

[yourjelly]

Ugh, I did it again. I though I figured out what I did wrong last time

[Josh5]

Before you go too far down this road, try disabling buildkit on your local dev machine. It will make the output much clearer

[yourjelly]

Okay, I think I understand, what you're talking about and what's going on. This is definitely an example of I don't know what I don't know. And have been looking into other methods to build because what I'm doing now is not ideal.

Also while looking into buildkit I found what might be the solution to my read only errors https://forums.unraid.net/topic/98023-solved-read-only-file-system-error-when-creating-container/

That said, I'll retain that I find this more readable and easier to comment out and edit pieces.

[Josh5]

The big issue i have with what you have done here is it completely breaks the build caching. If you touch any of your build scripts, the whole image needs to be built from scratch. I also cannot see how this makes the install process any more readable. Perhaps it is better to just provide more context in descriptions around each RUN segment.

The initial issue you described could have easily been resolved by adding DOCKER_BUILDKIT=0 infront of your build command.

What you have done here is complicate the build process with many files that now need to be maintained instead of just the one. And while this is not necessarily wrong or bad, I do really question why it needs to be done.

If you want to join me in co-maintaining Steam Headless and make this arch based one in parallel with debian, i would consider these changes. But at the moment i still dont understand the benefits of trying to get everything from holoiso into a docker image. In my mind, you are only going to end up with a massively bloated arch based kde desktop with functionally in it that does not work properly due to the lack of init system or flatpak support and ultimately, the games themselves will play no better the they do inside a docker container based on debian slim. I say this not because I want you to stop trying or submitting PRs, but purely because I dont yet understand your end goal here and it would be cool if you could explain that to me.

[yourjelly]

I am still learning a lot with all this stuff. The reason I thought this change was helpful or the better way to do it is because that was how I had seen it done when first digging into dockerfiles.

The big issue i have with what you have done here is it completely breaks the build caching. If you touch any of your build scripts, the whole image needs to be built from scratch. I also cannot see how this makes the install process any more readable. Perhaps it is better to just provide more context in descriptions around each RUN segment.

The initial issue you described could have easily been resolved by adding DOCKER_BUILDKIT=0 infront of your build command.

So again I'm inexperienced and don't actually know what is going on but I believe with buildkit on I have seen it do caches of the scripts steps and skip ones that have not changed. Likewise because I was building your project with buildkit on I had the opposite problem where with the large dockerfile the steps weren't being chached and changes to it need the whole thing rebuilt.

I believe I am far to inexperienced to provide anything useful in a co-maintainer sense. My plan starting the project of integrating holoiso was to see if I could and see what I could learn along the way. I had no expectations of better performance or w/e just to see what I could do.

If it doesn't provide a benefit that is fine and I'll close this, and probably keep working on the holoiso stuff for a while to keep learning stuff.