Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian still having trouble with merged /usr

lwn.net

Post reply on HN
Print view View original

191–200 of 310 posts

Re: Debian still having trouble with merged /usr

#191

Post by Beltalowda »

josefx wrote: post #129
Zardoz84 wrote: post #81

Giving that on Ubuntu this was done (and in other distros), and there isn't any issue ( I just noticed that I have a merged /usr for a long time), the dpkg maintainer it's being a jerk.

As far as I can find there are issues, namely that installing a package with dpkg can leave the system in a bad state. If I understand it correctly dpkg normally prevents by checking the paths it modifies, which ends up non trivial if the paths are aliased. > the dpkg maintainer it's being a jerk. He is required to accept working patches, priority by the committee seems to be the removal of warnings about the broken…

> He is required to accept working patches

The thing is that no one wants to interact with a maintainer hostile to the very idea of your patch. Sure, they may be "required" to accept it, but it's not going to be a fun process for anyone involved.

Part of Boccassi's concern with their patch is that it might not be merged at all due to what they perceive as "moving goalposts" and "excuses". I think that's not entirely an unreasonable concern, and no one likes to work on patches that will never get merged.

I don't know what the path forward for Debian would be here. Things seem ... difficult. Getting some of the social tension solved and having people "kiss and make up" would probably be a good start, but that can only work if people are willing.

Re: Debian still having trouble with merged /usr

#192

Post by Zardoz84 »

codedokode wrote: post #104
Tor3 wrote: post #9

I understand the problem dpkg is facing (can't know the canonical pathname for an object is, in some cases), but I have huge problems understanding why a symlink farm is preferable. The last thing I want to see on my Debian system is directories with hundreds or maybe thousands of symlink entries. There must be a way to let dpkg do its job if the directory-symlink approach is used instead, surely? (/bin -> /usr/bin)

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

Ubuntu uses dpkg and have the merged /usr using the directory-symlink without any issues.

Also, I don't see how a folder filled with symlinks would prevent the problem that are you talking.

Re: Debian still having trouble with merged /usr

#193

Post by dogleash »

WhyNotHugo wrote: post #148
iso1210 wrote: post #52

> The /usr merge idea was first raised in "The Case for the /usr Merge" by Lennart Poettering in 2012. It came out of the systemd community Well that's a recipe for a long drawnout battle

Yeah, ideas and projects are often dismissed due to coming from the systemd group. For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.

>usable in plenty of non-systemd environments

That's really unfortunate naming then. Any systemd-foo that "works on it's own" is (rightly) assumed to be tightly coupled to the rest of the systemd ecosystem.

Re: Debian still having trouble with merged /usr

#194

Post by Zardoz84 »

jillesvangurp wrote: post #124
iso1210 wrote: post #52

> The /usr merge idea was first raised in "The Case for the /usr Merge" by Lennart Poettering in 2012. It came out of the systemd community Well that's a recipe for a long drawnout battle

As somebody who really does not care either way, all this just sounds more like moving problems rather than solving a problems. At least, I don't think there are many Linux systems where you can safely remove /bin from the path just yet. I just checked. My Manjaro install has a /bin and it is full of files that look like I would not want to lose them. So, they fixed the /bin to /usr/bin thing for some packages but cl…

have you tried Slax ? Had that mounting packages thing many years ago.

Re: Debian still having trouble with merged /usr

#195

Post by Beltalowda »

WhyNotHugo wrote: post #148
iso1210 wrote: post #52

> The /usr merge idea was first raised in "The Case for the /usr Merge" by Lennart Poettering in 2012. It came out of the systemd community Well that's a recipe for a long drawnout battle

Yeah, ideas and projects are often dismissed due to coming from the systemd group. For this very reason, I'm rather bothered that gummiboot was renamed into systemd-boot. It's a very simple, nice tool, that's usable in plenty of non-systemd environments... but the naming just makes it unpopular with the crowd that doesn't like systemd.

I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption.

I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". Well, maybe, but you broke my system and before it was perfectly fine, and that's kind of an issue for me. Especially with something as critical as booting my system, I want to be able to just rely on it without breakage "because I was using it wrong". Linus' "we don't break userland"-policy was a great piece of insight. I wish systemd had a similar attitude.

Some of the systemd criticism has gone off the rails (...and then some...), but there's a number of things one could reasonably criticize about the project and development style, IMHO.

Re: Debian still having trouble with merged /usr

#196

Post by Beltalowda »

upofadown wrote: post #131

>Improved compatibility with other Unixes/Linuxes... A quick check reveals that OpenBSD presently has separate /bin and /sbin. FreeBSD also has a separate /lib. Exactly what were the other Unixes/Linuxes that this was supposed to improve compatibility with? I hope was not just Solaris...

OpenBSD also has /usr/X11R6, where it puts the X stuff (their X distro is named Xenocara). This is another piece of legacy from back when you might want to have both /usr/X11R2 and /usr/X11R3. These days the X11R6 directory actually contains X11R7 shrug.

FreeBSD used to do this too, but got rid of it in FreeBSD 6 (I think? Maybe 7? About ten years ago).

Both systems install packages to /usr/local.

Re: Debian still having trouble with merged /usr

#197

Post by deknos »

sph wrote: post #4

Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…

on the other side, debian is one of the most stable platforms, more than even commercial ones (binary compatible centos is just a blink in the lifetime of debian for example :D) .

just because people care about the technology...

and upgrading is important for small business with less money. and this shows how hard it is to achive an good upgrade path.

Re: Debian still having trouble with merged /usr

#198

Post by zh3 »

I've always liked the /usr distinction, with systems set up so they will at least boot without /usr mounted (at an absolutely minimum, a statically linked /bin/sh is enough to get a command prompt). This is particularly valuable for setups where a large number of PCs can mount /usr read-only from a remote server (we run quite a number of diskless x86 amd ARM systems like this).

Re: Debian still having trouble with merged /usr

#199

Post by BlinkenBlinken »

tenebrisalietum wrote: post #164
BlinkenBlinken wrote: post #158

Current state of the UNIX file hierarchy is a mess. Many incarnations of GNU/Linux systems didn't contribute to a more elegant yet simplified directory structure. Just pick the one you like the most and serves the purpose of your desires. As for merged /usr, recently using Arch Linux for desktop use. Works decent enough to getting things done.

Elaborate. I don't find the UNIX file hierarchy complicated, but there are some historical quirks and artifacts (like `/var/lib`). The difference between `/usr/X` and `/X` is about the worst of it IMHO. Everything important is usually at most 3 levels deep and the short names are very convenient (versus "C:\Users\xxx\Documents and Settings"). Compare to things like Windows: c:\windows\system32 that has 64 bit stuff i…

I like to point out that I'm in favor of standardization of directories. Also understand the legacy argument since a lot of software, by default uses it's file location.

Directories like var, opt, usr need some rethinking. Hence the UsrMerge I presume?

This is what the current filesystem looks like: """ lrwxrwxrwx 1 root root 7 Apr 6 15:21 bin -> usr/bin drwxr-xr-x 3 root root 4096 Apr 6 15:30 boot drwxr-xr-x 17 root root 3400 Apr 6 15:31 dev drwxr-xr-x 67 root root 4096 Apr 6 15:32 etc drwxr-xr-x 3 root root 4096 Apr 6 15:30 home lrwxrwxrwx 1 root root 31 Apr 6 15:24 initrd.img -> boot/initrd.img-5.10.0-13-amd64 lrwxrwxrwx 1 root root 31 Apr 6 15:24 initrd.img.old -> boot/initrd.img-5.10.0-13-amd64 lrwxrwxrwx 1 root root 7 Apr 6 15:21 lib -> usr/lib lrwxrwxrwx 1 root root 9 Apr 6 15:21 lib32 -> usr/lib32 lrwxrwxrwx 1 root root 9 Apr 6 15:21 lib64 -> usr/lib64 lrwxrwxrwx 1 root root 10 Apr 6 15:21 libx32 -> usr/libx32 drwx------ 2 root root 16384 Apr 6 15:20 lost+found drwxr-xr-x 3 root root 4096 Apr 6 15:21 media drwxr-xr-x 2 root root 4096 Apr 6 15:21 mnt drwxr-xr-x 2 root root 4096 Apr 6 15:21 opt dr-xr-xr-x 173 root root 0 Apr 6 15:31 proc drwx------ 2 root root 4096 Apr 6 15:32 root drwxr-xr-x 17 root root 520 Apr 6 15:34 run lrwxrwxrwx 1 root root 8 Apr 6 15:21 sbin -> usr/sbin drwxr-xr-x 2 root root 4096 Apr 6 15:21 srv dr-xr-xr-x 13 root root 0 Apr 6 15:31 sys drwxrwxrwt 9 root root 4096 Apr 6 15:32 tmp drwxr-xr-x 14 root root 4096 Apr 6 15:21 usr drwxr-xr-x 11 root root 4096 Apr 6 15:21 var lrwxrwxrwx 1 root root 28 Apr 6 15:24 vmlinuz -> boot/vmlinuz-5.10.0-13-amd64 lrwxrwxrwx 1 root root 28 Apr 6 15:24 vmlinuz.old -> boot/vmlinuz-5.10.0-13-amd64 """

What goes where. I have been a sysop for a long time. Came from a time that computers where simple by comparison to now. Limited in functionality, but just worked. Seen many changes. I the past there were less directories. Though time we added a couple. E.g. opt, srv, media. Or the dev, proc and sys. What happens when something new popup? Create a new directory? Possible. Maybe now is the time to consolidate and rethink certain directories? Better names? E.g. system instead of usr. Location where put libraries, maybe consolidate into one? Location for data (stores)? Etc.

Off cause current hierarchy isn't complicated. But it's not intuitive and can be confusing. Even the windows directories are better readable? I think naming must be more intuitive. Especially with regards to new or inexperienced user. Just an idea. Make unix accessible to everyone is a good goal.

Starts with readability in my opinion.

Oh, didn't mention software development. Which is an entire different ballgame with respect to device files, magic files etc. Ugly to boot. The mantra everything is a file is also not true.

It's just my opinion.

Re: Debian still having trouble with merged /usr

#200

Post by gompertz »

voidfunc wrote: post #180
BuildTheRobots wrote: post #175

Earlier quoted context omitted.

The obvious followup question that jumped to mind is "what's the difference between /bin and /sbin?". Both contained files required to boot in single user mode, however /sbin contains executables not usually executed by normal users. sbin short for "System Binaries" maybe?

I always understood it as statically linked binaries that could be used regardless of the state of the rest of the system.

Both /bin and /sbin are generally statically linked. So you're not wrong; but primarily sbin is intended to mean "executed by root" above all else.
Post reply on HN