q66
commented
2 years ago In the end I've come to the conclusion that I will be forking bsdutils. Since this repository does not appear to be super active and a lot of the work done in the past year has been driven by my efforts anyway, I'd like to take control in my own direction, prioritizing the needs of the distribution regarding packaging and releases as well as overall code organization and composition of the ports (I will be merging bsdutils-extra into the new fork as well, and turn it into a more complete userland package).
I will leave the existing pull requests open if you need them, and I have significantly more work done in my wip branch as well that you are free to take if you wish: https://github.com/chimera-linux/bsdutils/commits/wip I will leave this repository frozen in place.
Thanks for all the work you have done on the project.
hi,
i am curious if you'd be interested in moving bsdutils maintenance under https://github.com/chimera-linux, since it relies on bsdutils for its core userland and realistically probably gets the most testing in there/is the biggest user? Chances are it could get more development/attention/focus that way, plus potentially better infrastructure as well.
If not, that's fine of course (i'll probably just continue making pull requests here as needed)
There are some things I am investigating currently:
1) a multicall binary option (I believe I have a way to do this that is minimally invasive when it comes to patching, and this would enable me to replace klibc and busybox in places like compact initramfs environments) 2) a fine-grained way to enable/disable individual tools (especially useful together with 1) 3) I am thinking whether we could merge my other ports of FreeBSD tools in here, even stuff that is beyond coreutils (stuff like grep, sed/ed, m4, gzip, patch, diff) in order to have a shared build system; this would make 1) and 2) further useful