[Sugestion] Statically Linked Binaries

[xplshn]

Hi! I am the creator of BigDl, and it is also written in Go, I thought it'd be beneficial for Copacabana to use existing repos, my binary manager uses Toolpacks as its main repo, and my repo of shellscripts too, Toolpacks gets updated every 2 days, every binary is rebuilt in a Github Action and Metadata for the binaries gets generated at the same time too, so you can actually even implement an update mechanism and keep track of things. (bigdl does that already).

Please have a look and tell me what you think, it the first serious Go project I've written and so things aren't really done in the best possible way... https://github.com/xplshn/bigdl https://github.com/Azathothas/Toolpacks https://github.com/Azathothas/Static-Binaries

All binaries are statically linked

[takusuman]

It seems like you have read my mind. I'm thinking about changing this project name and start working on it again. I've been to busy with college and other projects for Copacabana (such as Heirloom itself). I will take a look, I think it will work fairly well until this project gets done. The idea here is to have a fail-proof package manager, based on the SVR4 model, but this project really looks promising as a "homebrew" way to get extra programs that we may do not package.

[takusuman]

By the way, it would be a blessing if I could move this to the Copacabana repository.

[xplshn]

By the way, it would be a blessing if I could move this to the Copacabana repository.

That'd be fine with me

In any case, bigdl can be relicensed to 3BSD if it suits you better, and I think you could simply convert each .go file into its own program, bigdl is really flexible, I have a version of it that is a single .go file too, and only one external lib is used (progressbar, and a faster json lib is optional, in the fast branch), I'd also suggest using https://github.com/u-root/gobusybox in case you do separate each functionality into a separate program, so that you can use a symlink and have it be lighter and faster...

I really hope to see a good Linux distro that isn't just a coat of paint over a few programs and a broken set of patches over SUSV4 programs. I thought CobaltBSD looked promising but development came to a halt it seems.

[takusuman]

I think you could simply convert each .go file into its own program

This package manager is meant to be made exactly this way, since there will be separate programs for separate functions. It differs from bigdl in the sense that it doesn't do anything apart from installing, creating and removing packages like it's in the specification from February 2000. Knowing about bigdl is very helpful right now because I know this won't be completely done until August, so another way of installing packages cosily would be great.

[takusuman]

The fact that it can download into $HOME is a killer feature to me.

[xplshn]

The fact that it can download into $HOME is a killer feature to me.

The $BIGDL_CACHE var and $INSTALL_DIR can be pointed to any place, I think run is great for scripts too, so you can keep the system very lightweight. Anyways, if you do end up using it, please tell me what you think, and in case you make patches, make a PR :)

[takusuman]

Anyways, if you do end up using it, please tell me what you think, and in case you make patches, make a PR

I will get this packaged for Copacabana in the next release, it is really helpful. My real preoccupation for now is making the system itself. I already did once, but it was with GCC and the process was manual enough to produce an enormous "paper" about cross-compiling Linux, and I wish I could make this more automatic and this will probably take some time before I can work on the package part itself. I probably need to refactor Copacabana's build system since its getting too complex in comparison to something made using pure Makefiles.

[xplshn]

Have you checked out Sabotage Linux's build and bootstrap scripts? They are a good resource, and their build scripts for some packages too, I also love their netbsd-curses and other drop-in replacements for GNU things

[takusuman]

Have you checked out Sabotage Linux's build and bootstrap scripts? They are a good resource, and their build scripts for some packages too, I also love their netbsd-curses and other drop-in replacements for GNU things

I didn't remembered about it. I will take a look tomorrow (here is about 1:57 A.M.) after I finish some college affairs and then study these. Thanks, I appreciate it.

[xplshn]

Have a good evening hermano, wish you luck