It would be possible to install individual RPMs into paths such as: ~~~ /pkgs/programA_version1 /pkgs/libX_version1 contains ~~~ but I wonder how would you imagine the glue above this structure to make the programA_version1 to use the libX_version1? Vít Dne 22. 05. 20 v 21:50 Paul Dufresne via devel napsal(a): > 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
