Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
A_brief_story_of_hier (andrewdomain.com)
21 points by cassepipe on Feb 8, 2024 | hide | past | favorite | 8 comments


> So ideally there should be a neat distinction between all the binaries that only root can execute,

I don't see why, and this is never justified. If the distinction is required, the mere location of the binary is probably insufficient and certainly not required.


> I don't see why,

chmod 700 ?


Glossed over: merged /usr broken all sorts of tooling.

For example, `command -V sh` now returns `/usr/bin/sh`, which is not `/bin/sh`. Among other things this means it is no longer possible to generate shebangs and have them actually work on similar systems.

Also, `dpkg -S` is now completely broken for the common case where its argument is the result of the above or `realpath`, and the two parties who are collectively responsible just say "screw you" to the other instead of fixing things.

As a result, every single package-checking script out there has to now do a dance:

* does the requested path start with /bin/ or /usr/bin/, /sbin/ or /usr/sbin/, /lib* or /usr/lib? If so, check both. This can requires significant refactoring. * Otherwise, fall back to the old code that used to work unconditionally.

(I'm only familiar with Debian's breakage but I expect most other distros have similar breakage)


That sounds... wrong? Why would you be generating shebangs for other platforms? The shebang should be generated on the local system, so it should always be correct on the local system, whether it is /bin/sh, /usr/bin/sh, or /did/you/know/sh/path/and/shebang/is/not/standardized?


Keep in mind that "other platforms" includes "different installs of the distro that haven't done the /usr merge yet" and "very close forks of the distro", but in practice copying it to any distro still worked.

And of course you haven't considered the "what package installed this file" half of my post.


Don't understand your concerns. Symlinks remain for compatibility. No need to change any tooling.


Symlinks let you run unmerged software on merged systems, but actively break running merged software on unmerged systems.

And of course you haven't addressed the "what package installed this file" half of my post at all.


This is basically just a debian problem. Other distros just did a merge, stopped supporting an unmerged version, and made their tooling work properly. Debian is still stuck in the middle because of said parties.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: