Please demonstrate how the example I gave above can be done with common scripting tools, such it would mimic the declarative experience I described. I don’t think it is possible as you claim.

Can you please point to where I deflected any questions? I looked and could not find any instances of such.

I actually answered the question “why”, please refer to previous comments. It is also answered in the main post. But I will rephrase and summarize again here:

• when creating a container image that requires certain applications installed, most dockerfiles explicitly install the dependencies of said applications as well. With my tool, you only declare the package you need, and it will resolve dependencies automatically and install them for you.
• the above would work with distroless containers too, as the package manager used is outside of the produced container.

Distroless is not core to the idea. It’s only a nice to have. The main point is the composability, Declarative design, etc.

the base image is nodejs

Which has its own dockerfile. My proposed tool would allow using other images as base too, but that is not the problem it is solving.

copy your app

Well you’d have to have it compiled or built if that is required in your case. With my system, the build recipe would be a gentoo ebuild (shell-script-like) that you would just reference.

The example I gave is pretty simple, you’re right. Say in another case, you list the following packages:

nodejs, nginx, vpn-app(wireguard), some-system-monitoring-app, my-app

You could start with a nodejs base or an nginx base, and then write the steps to install the other. You’d also have to make sure to get all the deps if they have them.

You’re unlikely to find a ready image that has all what you want. But with my method, you can compose different ones however you like, rather than having to find an image that matches your exact use case.

I had a feeling nixos would have something, but I avoided it because it seemed more than a day’s worth of learning (and also its a bit opinionated). But I will revisit it one day!

Did not know about apko. I am not attached to distroless, just thought it was a nice to have. So apko might be a reason I don’t pursue this project anymore. Thanks for showing me!

Your comment is very insightful for other reasons too. Thanks a lot :)

The package manager would not be part of the container image. The package manager is only used to build it. The container image will only include the packages the user specifies.

combining portions of images as multi-stage builds

That’s something I am making use of for this, actually :)

What you’re describing not only already exists…

Can you please give an example of a tool that can build a container image by being given only a list of packages it needs to have?

My tool would be as simple as doing something like this:

build-container --packages nodejs-20.1.1, yarn-4.2.2, some-app-i-made-1.0.0

And I would have a container that only has nodejs binary, yarn, and my own app. no package manager or any utils.

I tried it about a year ago. I don’t remember why I left it, but I think I did have a couple issues with it related to nvidia. I’ll try it again.

Gitea claims to be working on federation too, which puzzles me that forgejo presents it as a differentiator.

Pulling in mainline gitea changes, I did see. But I didn’t see any notable differences from gitea. Do you know of any?

Not very clear to me that this is any more valuable than OG NixOS.

This sounds a lot like the forgejo vs gitea fork. I love the forgejo people but I am yet to see a sufficient differentiator.

I like fuzzle as a rofi alternative for wayland. It’s made by the same developer as Foot terminal.

How does it compare to XFCE

I agree, but I think it does cross the minds of many. They just still choose not to care.

Didn’t say you can’t whatever you want. I said “by your logic”. That was assuming you don’t contradict your own logic, but of course you can otherwise :)

By your logic, you cannot dismiss the project for being a personal one. Only if it fails, is it dismissable.

Given they mention arch and gentoo, I suppose they intend it as a daily driver / desktop.

I haven’t really come into any issues on lemmy. Can you point to an example?

I see. I have little knowledge, but I bet that the “root privileges” part of this process is the reboot. Upon rebooting, system updates are applied from the new image via some privileged process.

That’s pretty neat. Unfortunately I haven’t ventured deeply enough into that type of system yet (was it called immutable distro or something?). I use gentoo, which doesn’t support this out of the box.

Thanks for showing me something new!

Only the root user has access to system updates on my system currently.

What does rpm-ostree update do exactly? Does it execute the update? Or is that the rebase command only?

Yes I did, and that’s a very good point. What sudo does not allow me to do is grant a user access to modify or read specific files or directories. I can get both that and access to executing specific programs using a users/groups permission system.

Another thing I don’t like about sudo is that you end up using the same password for everything, which is also the password for logging in. Putting higher privileges behind my same login password opens me to a single point of failure.