3 ms·

> Debian put the idea through a committee, of course a minority wanted to keep the old behaviour That is specifically not what happened, and the article is qui

• sph 5y ago
  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.
  • derefr 5y ago
    > 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.
    • sph 5y ago
      Well, this hasn't happened, and now we have the situation mentioned in this article.
    • josefx 5y ago
      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.
  • onei 5y ago
    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.
  • mjevans 5y ago
    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/'.
  • makomk 5y ago
    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.
    • gtirloni 5y ago
      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.
    • sph 5y ago
      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.
• izacus 5y ago
  You're spreading misinformation too: based on the article the dpkg maintainer is trying his hardest to obstruct fixes and implementation of the feature despite the voting and consensus.