A_brief_story_of_hier

https://andrewdomain.com/posts/a_brief_story_of_hier/

by cassepipe • 2 years ago

21 8 2 years ago

o11c3• 2 years ago

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)

ktpsns• 2 years ago

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

o11c3• 2 years ago

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.

Ferret7446• 2 years ago

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?

o11c3• 2 years ago

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.

rcxdude• 2 years ago

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.

emmelaich• 2 years ago

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.

hulitu• 2 years ago

I don't see why,

chmod 700 ?

A_brief_story_of_hier

Related Stories