On Thursday, March 21st, 2024 at 22:45, Rob Landley <r...@landley.net> wrote: > On 3/17/24 14:52, Oliver Webb wrote:
> > Also a problem if you want to switch Version Control systems or distribute > > tarballs without a .git/ directory. > > I already DID switch version control systems (from mercurial to git), and I > already distribute release tarballs. Why do you think these are new issues? I... Never said that those were new issues? Ones that would happen if we were to hide these in a new branch yes, but not new ones. > > Same here, I can remember the posix commands. > > Can you? I still have to check some from time to time, and the definition of > whether "tar" is a posix command or not is outright eldrich bordering on > quantum. I can certainly remember them better then the LSB commands. Most of the time I can remember if a command is in posix, which is what matters when trying to find it usually. > Back in 2012, when the number of commands was growing fast and having one big > directory of them all was getting a bit busy, the alternative of sorting them > into directories was annotating them with tags, and THAT was a nightmare (of > the > "this command has three tags" variety). And also implied future pressure to > extend the existing kconfig implementation to USE the tags, which would be > worse. > > Moving them into subdirectories, with each command in ONE directory, and a > README explaining what the directory was for, with kconfig automatically > displaying them in menus and using the first line of the README as the menu's > title, seemed the least bad crowd control option at the time. I did recognize that there was probably technical discussion behind this in 2012/2013 when they were moved. Asked about it later in the email too. Nice to know. > Collapsing the directories together when the last command is > promoted (or deleted) out of pending might make sense, What would happen when a new command shows up and we need to evaluate it then? Or glibc does a new release and yet another thing breaks we need to demote and re-promote eventually? > I also note I think I've figured out how to replace kconfig: I can just make a > list that scrolls up and down with a highlighted entry you hit space on, > handle > help text, search, exit/save, resolve selects and depends and have "menus" be > a > label line with its contents nested two spaces further to the right. [Some paragraphs bikeshedding about kconfig use to be here, may they rest in a text file until we get around to doing the kconfig rewrite] > > A possible solution is to... > > ... > > > Then again... > > I need to stop checking email every time I sit down at my laptop, because > bikeshedding can eat an endless amount of time and I've got other stuff to do. > > For one thing, I promised to look at > https://github.com/landley/toybox/issues/486 tonight. Sorry for getting in the way of that, the technical discussion about it was interesting enough to me to respond to. Recently found something to run off to and do while still benefiting toybox, so I'll stop bikeshedding about stuff like this. > P.S. I never mind people asking "what's the status of" or "why didn't you", > and > when people say they don't personally like stuff they can never actually be > WRONG about that. But suggesting what I "should" do is... tiring. I never thought about it in a "what should I make the maintainer do?" way, more in a "what benefits the project and makes it more usable?" way, considering possible solutions to issues. Sorry if it seems like I'm trying to order you around. I also stated in the email that reorganizing commands would be unfeasible, I talked about a possible way it could've been done "better", but I didn't say you should do anything. - Oliver Webb <aquahobby...@proton.me> _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net