menu-based DEPENDS

[v4hn]

Modules with many optional dependencies, like mpv, ask users many questions consecutively and it feels like a marathon to answer them all.
Even worse, if you accidentally make any mistake, the best thing you can do is CTRL+c, run lin -r module, go through the whole sprint again and hope to get it right this time.

To reduce these issues, it would be nice to have a CLI menu (likely using dialog) to select choices for a package, also remembering previous choices the user made.

An obvious short-coming of this idea is that the recursive nature of the dependency selection process is not available in the proposed menu. Instead of a nice-looking list of questions, this becomes a bombardment of dialogs.
But leaving it to the user which one they prefer should takes care of that.

[sobukus]

To rehash my idea from the beginning of my use of $SISTER_DISTRO: We need declarative configuration that then can be presented and worked on as a tree, just like Linux and busybox menuconfig with differing shells. Full nonlinear jumping around tweaking bits, seeing the effects (Nooooooooo! I do not want that mess pulled in, disable this feature instead!), and then commit and exec the build later.

The configuration scripts are de factor mostly declarative already. We'd need a switch to force them to be just declarative, or at least have only a small part of them actually active, emitting the declarative form on execution. Then there's a tree of configuration choices. Plaster menuconfig on top if it and done.

Of course you still need to nest things … like configuring busybox or the kernel triggering its own instance of menuconfig. But that shouldn't be a hindrance for anyone managing to unserstand recursion without first having to understand recursion, right?

[sobukus]

To clarify: The ‘we’ I use is a hyptothetical collaboration between Lunar and the other still active Sorcerer fork/continuation to settle common bits of the packaging format and possibly configuration logic.

[sobukus]

Oh … and a last thought: The linear working on the config like now should still be supported to be able to claim that all you need is basic tools and bash as runtime. But I wouldn't dare to implement the nonlinear tree config in bash. Personally, I'd use Perl, or perhaps just plain C as a no-nonsense basic choice. Of course people can have wildly differing opinions on that one. I'd at least caution to shy away from anything that needs e.g. llvm built on a gcc-based base image as dependency first. Someone will say Python. I will curse that person, perhaps, but I'd understand the uttering to some point;-)

It's a recurring discussion to what limits the package management using plain bash should be taken. I guess you can code anything in it if you only try hard enough, just to show that you can. Maybe the configuration value store and management of the tree it self can be a stand-alone little server (pipe in/out) for the configuration session and the presentation is still done with bash and dialog.