Brew, but better. I see a bright future ahead.
Tools will bundle all their dependencies.
So no Python, no Java
Honestly for the best lol.
Jokes aside, I don’t see why this would exclude those languages. Just because they need a runtime doesn’t mean the runtime can’t be bundled (even if it is annoying to do so). I would imagine for runtime-dependent tools, they would just make a generic runtime bundle that can be shared between packages, similarly to how it’s done with flatpak.
I think “tools [bundling] all their dependencies” is more likely to mean that you need to ensure that third-party libraries your tool depend on are bundled, which is good. End users, even if they’re developers, shouldn’t need to hunt those down just to use something.
On the other hand, I feel like many of the headaches of packaging and using packages could have been avoided if static linking were the default. Sure, things like openssl should probably be dynamically linked for more immediate updates when security issues arise, but most of the other third-party libraries for applications should be statically linked.
Otherwise, we end up reinventing static linking for decades, which is what things like Flatpak, AppImages, Snaps (🤢), and presumably Toolpaks exist to solve.
Yes, Flatpaks and Snaps (🤢) also provide application sandboxes, but it would be much better if they could focus more on sandboxing than also having to worry about dependency management for application libraries.
Arguably, if static linking were the default, Toolpaks wouldn’t be necessary either, even for immutable systems, because static binaries can be easily installed to a mutable part of the system.
Just one big black box binary.
Security people should lose their minds … or their accreditation.
Hopefully it will be open source, so you can build it yourself. It seems to be related to gnomeOS…
In the mean time, if you have any other feedback, find us in #gnome-os:gnome.org on Matrix, or leave a comment.
