33
Introducing Toolpak (blogs.gnome.org)
submitted 1 month ago by to c/linux@lemmy.ml
9 comments fedilink hide all child comments

all 9 comments

sorted by: hot top controversial new old
[–] 3 points 1 month ago

Guys, nix or guix

The problem is already solved

  • permalink
  • fedilink
  • source
    •
    [–] 2 points 1 month ago

    Brew, but better. I see a bright future ahead.

  • permalink
  • fedilink
  • source
    •
    [–] 2 points 1 month ago* (6 children)

    Tools will bundle all their dependencies.

    So no Python, no Java

  • permalink
  • fedilink
  • source
  • hideshow 6 child comments
    •
  • [–] 5 points 1 month ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 month ago*

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 month ago (2 children)

    Just one big black box binary.

    Security people should lose their minds ... or their accreditation.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
    • 1 comment in c/linux@programming.dev view that post
    [–] 2 points 1 month ago

    Tools can not depend on other tools. One of the issues with traditional distributions is dependency resolution and package management (this is subcategory of a heavily discussed topic, I also talked about it in my LAS talk from 2025. We should avoid making individual packages or having dependencies between tools, to avoid all the unnecessary complexity that comes with it.

    I was getting excited about this, but this point might be a big dealbreaker. The C compiler for example will need to find manually installed headers and library files when you need to compile more than a hello world, and often tightly interacts with pkg-config, cmake etc.

    I fear you'd have to be working in a container anyway for some scenarios, unless there's some other parts not explained in the post.

    I'm also not a fan of the possible gatekeeping of who can create these tools, via signing and trusted repositories, but it's probably going to be fine in the end.

    TBH toolbx is quite a good environment to work in already. I would just have liked a bit more sandboxing though (i.e. have a way for it to not mount my home)

  • permalink
  • fedilink
  • source
    •