On 4/26/25 10:15, Bernhard Voelker wrote:
On 4/25/25 21:25, Pádraig Brady wrote:
On 25/04/2025 19:41, Bernhard Voelker wrote:
Is there a particular reason why we only have
--enable-single-binary=shebangs|symlinks
i.e., no hardlinks? It seems to work very well.
OTOH this might rather be a downstream packager issue?
It's a good question.
I can't remember any previous discussions on this.
I can't really think of a reason hardlinks would be preferred,
https://en.wikipedia.org/wiki/Symbolic_link#Microsoft_Windows
Microsoft Windows didn't support them before Windows XP, and until Vista
didn't allow "non-kernel mode apps" to create them. (Don't ask me how
that relates to the administrator account, or whether an "app" is a
process or an executable or what in that ecosystem. And of course before
that there were "shortcut files" which were just a minefield.)
Meanwhile the W2K problem already had cReatEhArdlInk() and falling back
to separate copies of the file from hardlinks is trivial: for read-only
files it's just a space optimization rather than introducing significant
new API surface area.
For updates the packaging system would have to handle
hardlinked files appropriately. IIRC rpm does have logic
for this, but I've not considered all edge cases, or other packaging
systems.
Indeed, that might be hassle for some.
Toybox only installs symlinks. Hardlinks work fine but I didn't bother
to implement any install plumbing for them: if you want that you can do
it yourself. The standard "install" target installs the multiplexer with
symlinks (and "install_flat" puts all the symlinks in the same directory
with the binary rather than distributing them under bin/sbin). There's
also a make "change" target builds individual standalone binaries (like
making change for a $20), avoiding the issue at the cost of several megs
of disk space and more runtime memory (but really it's mostly used for
testing purposes).
I do note there's a symlink hiccup where if you use what argv[0] says to
determine your behavior and you make a symlink TO a symlink (which
happens), your multiplexer plumbing can't just "unknown name" on the
first failure, it has to traverse levels of symlink until it finds a
name it understands to tell it how to react. And you can't just realpath
it because when "gsed" is a symlink to "sed" which is a symlink to
"toybox", then gsed would act like the multiplexer not like sed.
Also symlinks are more informative as to what binary
a particular command name is associated.
Also symlinks are more flexible wrt cross file system handling
(though that is unlikely I expect).
right, nowadays even /bin and /usr/bin are merged in some/all(?)
distributions.
I plead the 5th.
Rob
