I don’t think this is specifically about FHS as it is about shared library management. The underlying hierarchy defined in FHS doesn’t make the dictations about version management that you seem to indicate, nor are the major problems with maintaining multiple api compatible versions of shared libraries solved with a new hierarchy. As for hierarchal path collision, maintainers are constantly patching around a package’s default paths as it is, and there are always distribution specific hierarchy quirks that are patched for. It really isn’t infeasible just due to FHS, and as far as I understand it, modularity isn’t a salvation that will allow multi-version shared libraries to co-exist. Can you elaborate about what programs depend on these old library versions? I think generally speaking, when software depends on older libraries it is abandoned/unmaintained. If the library has important functionality isn’t it best to support efforts to revive development in the first place? Sent from my iPhone > On May 22, 2020, at 2:58 PM, Paul Dufresne via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > The File Hierarchy Standard (FHS), is a standard that define where the files of a package should be placed in the root directory of the systems. It probably did not change much since the beginning of Unix, and it make files be placed where users, developers and administrators expect them to be. > > The main disadvantage of it, is making hard to have multiple active versions of a package, because the likelihood of the multiple versions, to have the same preferred place in the hierarchy for some files. > > On other way of seeing this disadvantage, is the fact that in a system using FHS, new versions of packages often break other programs... because using FHS force you to erase the old package to put a new one in it's place... so that programs that were dependent on the old version cannot use the old version because it is not there anymore. > > You probably only realize all this, when you use a distribution like NixOS, that have let FHS go away, to make every binary package to be in their own directory. This solve the problem of multiple active versions of a package, and allows different packages to depend on different versions of a package. This also allows normal users to install package, just for them... or shared if many users install the same version of a program. > > Well... I was not so happy with NixOS. In part because binary packages are considered, a cache version of a built packages. In the past, often the binary cache was not having the built version of a package, and it had to build it from sources... which is long, especially if you have an older computer. I am unsure why this seems to be less problematic now than in the past. > > The other problem I had with NixOS, was the strange Nix syntax of packages. That I did not seems to get it. Now... with time, the more I am exposed to it, the less it seems strange. Still, I wanted a more traditional Linux distribution. I had thought that the fact that Fedora support modules, that it could be a bit like NixOS. Only recently, when someone suggested that we could use modules to have different versions of Python, avoiding the problem of new versions breaking old versions, did I really realized that Fedora modules does not allow multiple active versions of a module to be installed at the same time... so that Fedora modules does not help much with the problem of new packages needing to replace older versions, so breaking packages that were dependent on old versions. > > To be clear, the fact to be able to have multiple versions does not means that NixOS have many different versions for each packages. For some reasons, they try as much as possible to keep just one version of each package... but while upgrading... they may keep the older version a while. This reduce friction with other packages. > > Now like I said, Nix use a very different syntax and tools for defining packages. But I don't think you have to adopt it to have most of the advantages of Nix. And I believe it would be possible to keep the current use of .spec files in such a way of doing things. > > That said, I realize that what I am proposing, is more like a fork of Fedora, than a proposed change, as letting FHS is such a big change. And I am, sadly, not really suggesting that I want to begin such a endeavor. For me, it probably means I will begin to move to using more NixOS than Fedora. But I had the feeling that it could be useful for Fedora, to realize, and evaluate the price they pay for using the File Hierarchy Standard. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
