Hacker News Reader

Comment by sph | Hacker News Reader

I'm quoting the article:

"Debian took a more incremental approach, in part because it strives not to make wholesale changes to users' systems like those required by a flag-day upgrade to a merged /usr. In 2016, the ability to voluntarily switch to that scheme was added, then some attempts were made for newer versions of the distribution to be installed with a merged /usr by default. [...] The location of some files was being resolved at build time to point into /usr/bin (for example), but those files only existed in /bin on the non-merged systems."

The fact that the committee took a decision that the core package manager can't support is baffling to me.

View on HN

The committee took a decision that the package manager /doesn't/ support.

If I've learned one thing, it's that there's very little that software can't be made to do. Whether it should is an entirely valid question, and hopefully figured out before assessing the "could" aspect.

> The fact that the committee took a decision that the core package manager can't support is baffling to me.

Why? Presumably the committee would be thereby deciding to drive development of the package manager toward whatever is required to support the high-level goal.

Well, this hasn't happened, and now we have the situation mentioned in this article.

From a user perspective the high level problem would be merged directories. Which dpkg apparently already supports. Just not the way the committee wants it done.

> deciding to drive development of the package manager

Which is the hilarious part: No one seems to be working on it. The package maintainer for dpkg isn't required to it as long as he accepts reasonable patches, but only half finished patches (that identify themselves as such) are coming in when the reported issues are not outright ignored. Seems liked Debian suffers from the same issue every open source projects suffers from: A bunch of lazy and entitled as fuck users insisting on features without putting any effort in themselves.

Linux development in the present era is very heavily driven by Red Hat's needs and desires, and I don't think they have this problem because they don't support upgrading from one release to the next using the package manager - you have to reboot into the installer and do a kind of reinstall in place. So they can just require that all packages only have files in the non-symlinked directories after the flag day. Debian is different - you have to use the package manager to upgrade, which means you're going to be running with a mix of new and old packages at least for a while.

Are you talking about major RHEL upgrades? That's purely a support/business decision, not technical.

I've been upgrading my Fedora systems between major versions with yum/dnf for as long as I can remember. It just works.

Red Hat is not only RHEL. Red Hat's Fedora supports distro upgrades and they didn't have much issues pulling it off. I was using Arch Linux when the merge happened and it was a non-event.

It doesn't seem too difficult to support; what are the edge cases?

Who owns a file in a path that includes a 'well known symlink dir'?

So maintain a list of well known symlink dirs. When checking a file path against the database, the normalization step should check if the known symlink dir is any point of the path; if it is the redirect should be resolved to the well known target instead.

E.G. owns('/bin/bash') ... the path mutates to '/usr/bin/bash' because the location '/bin/' is already known to really be '/usr/bin/'.

Reply on news.ycombinator.com