What about using a real POSIX shell instead of making a filthy hack in the file system?

[takusuman]

I was reading doc/043-Create_Essential_Files_and_Links, and then i've read ln -sv bash /bin/sh. I disagree totally about linking bash to sh and my reasons are 100% technical.

So i've thought: "why not use a real POSIX shell?" My suggestions for a real POSIX shell are ash/dash (preferentially dash, because maintained and widely-used) and 42-shell.

I would like to know if y'all agree with me and would like to add my idea to the main source tree. I am totally available to help this time.

Thanks for the attention and please forgive me for possible grammatical errors (although practicing and using it everyday, my english still sucks).

[ghost]

Bash is POSIX compliant, so it works either way. I agree with you though, since musl is intended for minimal systems so why not use a minimal shell as well.

[dslm4515]

since musl is intended for minimal systems so why not use a minimal shell as well.

The goal of MLFS was not intended for minimal systems. If it was, some packages would have been replaced with busybox. The goal of MLFS is to build a basic GNU/Linux system with Musl instead of Glibc. I chose Musl for its advantages over Glibc:

Some of musl’s major advantages over glibc and uClibc/uClibc-ng are its size, correctness, static linking support, and clean code. https://wiki.musl-libc.org/

[dslm4515]

I am considering replacing bash with dash in my other repo, Optimux

[takusuman]

I am considering replacing bash with dash in my other repo, Optimux

That's a good idea, i use it in my Alpine server and i really like it. But what about OpenBSD's Korn Shell? I really like it, i think it'd be cool to take a try on it. It's complete and it compiles fast.

[dslm4515]

It's complete and it compiles fast.

Depends. Is it faster than Dash? :P

[dslm4515]

I'll look into it. I do believe Dash has less dependencies than bash... which is good for a "sand-boxed" toolchain

[owl4ce]

Dash is ultra closely-POSIX.

[takusuman]

It's complete and it compiles fast.

Depends. Is it faster than Dash? :P

Well, i didn't tested its speed, but it's a nice experiment to do in the future. 🤪

[dslm4515]

Currently I use pkgtools scripts from Slackware to add and remove packages but the scripts are Bash-based or have “bashisms” and those scripts fail with dash. I haven’t found a similar set of scripts or a package management I can use in place of pkgtools.

[takusuman]

Currently I use pkgtools scripts from Slackware to add and remove packages but the scripts are Bash-based or have “bashisms” and those scripts fail with dash. I haven’t found a similar set of scripts or a package management I can use in place of pkgtools.

I'm managing to write a decent package manager for my distro, but i didn't in fact started it yet.

[dslm4515]

I wanted to start developing one but I had questions.

For package creation, I would probably go with a similar method like Slackware: install built package to a directory then zip up as a package.

But for dependency tracking...I’m thinking of maybe utilizing some sort of database? Or maybe a directory tree with individual directories used as program groups and individual files that contains package name, version, description, and list of dependencies? If I use a directory of files, what’s the fastest way to parse to check for dependencies, package versions, etc?

[takusuman]

Let dependencies be managed by other program or "high-level script", keep it simple. Just make a file called dependencies and throw it in the package root; btw, i think i can help if you are going to do it in Shell Script.

In school summer holidays (which last three months and start in December for me here in Brazil) i intend to start coding my package manager, i'll make it in Go, based in what was specified in the "Application Packaging Developer's Guide" from Sun Microsystems.

[dslm4515]

Let dependencies be managed by other program or "high-level script", keep it simple.

Yes. I would design another script or software to check dependencies...separate from the other scripts that build, install, and upgrade packages.

Just make a file called dependencies and throw it in the package root; btw, i think i can help if you are going to do it in Shell Script.

Good idea. Then I won’t have to update a ‘dependency’ tree each time I upgrade a package. I may create the ‘dependency’ tree for a different purpose: so I know what packages to built first.

[dslm4515]

Just realized I probably can still use dash with pkgtools scripts as long as bash is installed BUT make sure each pkgtools script starts with #!/bin/bash instead of #!/bin/sh?

Otherwise, I’ll have to rewrite those scripts...and make them POSIX compliant

[owl4ce]

Just realized I probably can still use dash with pkgtools scripts as long as bash is installed BUT make sure each pkgtools script starts with #!/bin/bash instead of #!/bin/sh?

Yes.

[takusuman]

Just realized I probably can still use dash with pkgtools scripts as long as bash is installed BUT make sure each pkgtools script starts with #!/bin/bash instead of #!/bin/sh?

Otherwise, I’ll have to rewrite those scripts...and make them POSIX compliant

I know may it's late (because you already did some hacking on pkgtools to get them working on Musl-LFS or packages were already built), but what about using heirloom-pkgtools (GitHub mirror)? They're ported from Solaris, are made with portable C code and work pretty well --- I think they're more stable than Slackware's since they don't depend on external binaries, so you can compile them statically without fearing that you'd have "cannot open shared object file" after (or even while) updating your libc. It will just need a little hacking to work on Musl, but I don't think it's a big problem.

Sorry for bothering, but I've just remembered this now and I think it may would be nice to get those working on Musl-LFS.