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.
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@lists.fedoraproject.org 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 5/22/20 4:22 PM, Parker Gibson wrote:
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.
Ok... I am a novice about shared libraries... but here I think how it is supposed to work... more or less in Nix.
Now I do believe the reason you need to give a version to shared libraries is because of the FHS. Because FHS suggest to regroup libraries inside a specific directory and/or directories. But if you have a common directory that contains every packages inside their own directory, things because simpler because the directory identify uniquely a library.
So let's take an example:
At first you have:
/pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains /pkgs/libX_version1
/pkgs/libX_version1 contains libX, version 1.
Now you "upgrade" libX vesion 2... because each packages is in it's own directory, you create a new directory:
/pkgs/libX_version2
but you do not erase /pkgs/libX_version1 because it is still used by at least one program, programA.
Note that if you were using FHS, you would have to give a version number to the library file itself, because else it would clash with the old one, because they would be it the same directory.
Now, we eant to "upgrade" program A to version 2... that means we create:
/pkgs/programA_version2, while keeping programA_version1... because that's the way to upgrade in a system without FHS.
Now, the new /pkgs/programA_version2 is different than version 1 by the fact that it used the new pkgs/libX_version2 ... that is it's LIBRARY_PATH now contains pkgs/libX_version2, and not pkgs/libX_version1 anymore.
So you try the new version, it works. If nobody use programA_version1, you can delete pkgs/programA_version1 and pkgs/libX_version1 now.
On 5/22/20 6:23 PM, Paul Dufresne via devel wrote:
So let's take an example:
At first you have: /pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains /pkgs/libX_version1 /pkgs/libX_version1 contains libX, version 1.
Now you "upgrade" libX vesion 2... because each packages is in it's own directory, you create a new directory: /pkgs/libX_version2 but you do not erase /pkgs/libX_version1 because it is still used by at least one program, programA.
Note that if you were using FHS, you would have to give a version number to the library file itself, because else it would clash with the old one, because they would be it the same directory.
Yes, and there's nothing wrong with that! In FHS you have
/lib/libhogweed.so.4 -> libhogweed.so.4.5 /lib/libhogweed.so.4.5 /lib/libhogweed.so.5 -> libhogweed.so.5.0 /lib/libhogweed.so.5.0
An application requiring any v.5 links to /lib/libhogweed.so.5 and allows transparent upgrades from say 5.0 to 5.1, and the sad app that really depends on 4.5 links specifically to /lib/libhogweed.so.4.5. Normally a major version bump implies a significant API change, so it doesn't make sense to also have /lib/libhogweed.so -> libhogweed.so.5 because it would be impossible to assure future compatibility, but if someone came up with an API convention that somehow handles this, it is in principle possible and would completely decouple programs from system library versions.
Now, we eant to "upgrade" program A to version 2... that means we create: /pkgs/programA_version2, while keeping programA_version1... because that's the way to upgrade in a system without FHS.
Now, the new /pkgs/programA_version2 is different than version 1 by the fact that it used the new pkgs/libX_version2 ... that is it's LIBRARY_PATH now contains pkgs/libX_version2, and not pkgs/libX_version1 anymore.
So you try the new version, it works. If nobody use programA_version1, you can delete pkgs/programA_version1 and pkgs/libX_version1 now.
I think all the cases that you called out are handled with this scheme... and it saves us from the DLL hell with different versions of libs all over the place.
The issue I see is that no package management system I know of handles multiple so versions, they explicitly state packages conflict with each-other even if in principle the so versioning means they would not. Some repositories can handle multiple major so versions and I do think this may provide enough flexibility. I suppose the place of ultimate conflict is the devel packages as multi-version headers would always be in conflict, and I can’t imagine the nonsense one would have to go through to tell autoconf/pkg-config “no wait I want this specific version” in a shared library environment. But in principle there is nothing FHS related limiting multiple versions of a library. It’s an artificial limitation that probably helps ease the lives of package maintainers, it is not a technical limitation imposed by FHS.
Sent from my iPhone
On May 22, 2020, at 7:19 PM, Przemek Klosowski via devel devel@lists.fedoraproject.org wrote:
On 5/22/20 6:23 PM, Paul Dufresne via devel wrote:
So let's take an example:
At first you have: /pkgs/programA_version1 that have a LD_LIBRARY_PATH that contains /pkgs/libX_version1 /pkgs/libX_version1 contains libX, version 1.
Now you "upgrade" libX vesion 2... because each packages is in it's own directory, you create a new directory: /pkgs/libX_version2 but you do not erase /pkgs/libX_version1 because it is still used by at least one program, programA.
Note that if you were using FHS, you would have to give a version number to the library file itself, because else it would clash with the old one, because they would be it the same directory.
Yes, and there's nothing wrong with that! In FHS you have
/lib/libhogweed.so.4 -> libhogweed.so.4.5 /lib/libhogweed.so.4.5 /lib/libhogweed.so.5 -> libhogweed.so.5.0 /lib/libhogweed.so.5.0
An application requiring any v.5 links to /lib/libhogweed.so.5 and allows transparent upgrades from say 5.0 to 5.1, and the sad app that really depends on 4.5 links specifically to /lib/libhogweed.so.4.5. Normally a major version bump implies a significant API change, so it doesn't make sense to also have /lib/libhogweed.so -> libhogweed.so.5 because it would be impossible to assure future compatibility, but if someone came up with an API convention that somehow handles this, it is in principle possible and would completely decouple programs from system library versions.
Now, we eant to "upgrade" program A to version 2... that means we create: /pkgs/programA_version2, while keeping programA_version1... because that's the way to upgrade in a system without FHS.
Now, the new /pkgs/programA_version2 is different than version 1 by the fact that it used the new pkgs/libX_version2 ... that is it's LIBRARY_PATH now contains pkgs/libX_version2, and not pkgs/libX_version1 anymore.
So you try the new version, it works. If nobody use programA_version1, you can delete pkgs/programA_version1 and pkgs/libX_version1 now.
I think all the cases that you called out are handled with this scheme... and it saves us from the DLL hell with different versions of libs all over the place. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On 5/22/20 8:48 PM, Parker Gibson wrote:
The issue I see is that no package management system I know of handles multiple so versions, they explicitly state packages conflict with each-other even if in principle the so versioning means they would not.
The example I gave is from my own system. IN this case package 'nettle' owns all those libs, but the scheme would work just fine if one package owned the 4.x libraries and another one owned 5.x libraries.
The scheme you are proposing is kind-of used for Java and Go, and is sometimes known as 'vendoring' because it allows publishing software in complete dependency bundles independent of anything else. It works as long as the vendor is diligent about keeping up with it, but it just doesn't scale and leads to a fragmented and redundant setup, with decaying software all over teh place in those package bundles.
On Fri, May 22, 2020 at 09:14:14PM -0400, Przemek Klosowski via devel wrote:
The scheme you are proposing is kind-of used for Java and Go, and is sometimes known as 'vendoring' because it allows publishing software in complete dependency bundles independent of anything else. It works as long as the vendor is diligent about keeping up with it, but it just doesn't scale and leads to a fragmented and redundant setup, with decaying software all over teh place in those package bundles.
Here the vendor is Fedora. Fedora would have to track all these old versions and activelly remove them by rebuilding them against the new dependencies. Users would not notice.
But you are right that the possibility of vendoring makes a huge temptetion to upstreams to abuse and postponing porting to a new versions ad infinitum and that's the bitrotting you talk about, because distributions do not have a man power to overtake all the inactive upstreams. At the end, Fedora would remove the abandonded software.
It's also the same reason, which the original poster noticed, why NixOS tries to only keep one version of a package in the system whenever possible.
-- Petr
On Fri, May 22, 2020 at 07:48:53PM -0500, Parker Gibson wrote:
The issue I see is that no package management system I know of handles multiple so versions, they explicitly state packages conflict with each-other even if in principle the so versioning means they would not.
Gentoo portage when updating a package that changes a soname of a library installs the new package, but keeps the old library in the file system and remembers the reverse dependencies of the old library. Once all reverse dependencies are updates/rebuilt to use the new library, the old library is deleted from the file system.
Of course this is only a partial workaround because the old and new libraries can expect different (e.g. configuration) files and than the old library could malfunction. But in reality it almost never happen and the reverse dependencies are rebuilt sooner than somebody notices it.
Some repositories can handle multiple major so versions and I do think this may provide enough flexibility. I suppose the place of ultimate conflict is the devel packages as multi-version headers would always be in conflict, and I can’t imagine the nonsense one would have to go through to tell autoconf/pkg-config “no wait I want this specific version” in a shared library environment.
Why not? If an ELF executable can request a specific library version, then a build system could request the specific header or pkg-config files. Wrapping everything (a library and the headers) into a dedicated directory only papers out the real problem. The fact that nobody was bodered to implement a versioning into pkg-config files only shows that always building against the latest version is good enough. Technically a library can version pkg-config files on the name level (foo-1.pc, foo-2.pc) and projects that undergo a major API change do that. At the end if a library changes API, then the library user must be patched. Thus changing foo-1 into foo-2 in the user's code is the least problem.
But in principle there is nothing FHS related limiting multiple versions of a library. It’s an artificial limitation that probably helps ease the lives of package maintainers, it is not a technical limitation imposed by FHS.
Yes. E.g. DNF could keep more package versions installed (provided they do not conflict). It probably does not happen because the gains do not outweigh the expenses.
-- Petr
Paul Dufresne via devel writes:
Now I do believe the reason you need to give a version to shared libraries is because of the FHS. Because FHS suggest to regroup libraries inside a specific directory and/or directories. But if you have a common directory that contains every packages inside their own directory, things because simpler because the directory identify uniquely a library.
However, none of the above is entirely true, and the minor differences matter. You don't need to version shared libraries at all; the system (specifically ld-linux.so) will pick the first compatibly-named library on the load path. So you can specify different libraries by manipulating the load path (as well as several other mechanisms, some of which may not be available depending on the system's security posture).
The need to version shared libraries is not based on the FHS; it's that the library APIs or ABIs or semantics differ, so programs that target those APIs/ABIs/semantics can get what they're expecting (if they don't, often you get a core dump, or garbage output, or even a security vulnerability). We've learned over the ages for security and reliability reasons that these version variables and checks really need to be in the library and application respectively, so even if you wanted to go with a fully directory-based library search mechanism, you'd still need the version information. The libfoo.so.X.Y.Z naming convention turns out to be simple enough to be quite reliable for system administration, and the rare slip-up is caught by the version checks in the code.
The .so version *does* uniquely identify a library, regardless of directory (with some exceptions such as debug libraries that NixOS also presumably handles). But according to another poster, NixOS uses links to populate an application's library directory, so you actually don't know what those libraries are from their names. In principle; I suspect that NixOS enforces naming conventions so that you do know what they are, as long as you're using NixOS packages. But in the Fedora system, to find the library that will pass the runtime version checks you need to *both* name it correctly *and* be correct, since the version in the name needs to match the internal version.
And finally, the FHS does provide for I-don't-need-no-shared-libraries packages: it can't stop you from statically linking your executables (although GNU libc *really* doesn't like that for some facilities, like NSS), and it provides /opt for exactly the kind of package management you propose. Very few projects use it as far as I know (to check I'd have to find out what "LANANA" is exactly and look it up, see FHS if you wish to do so), presumably because of the benefits provided by shared libraries, some of which are described below (and of course there's the support that Fedora package management provides for the FHS but doesn't provide for /opt-style packaging).
All of your statements are "approximately" true (except the statement that FHS is a reason for library versioning) from the user's point of view. However, what you really are discussing is shared libraries themselves. If every binary had all its libraries compiled into it, this "DLL Hell" (to borrow from the Windows world) would never occur. So, why do we have shared libraries and DLL hell?
1. Space is limited, both on disk *and in memory*. A very basic library like ld-linux.so or libc.so is likely to have one hundred or more concurrent references on a moderately busy personal system. This saves a *ton* of swapping.
2. Bandwidth is limited. Upgrading a large number of packages would require upgrading each one's copy of shared libraries. Version dependencies means that you need to do that individually (although a Sufficiently Smart PMS could check for available versions on the system and copy them, you can be sure that will fail sometimes because the upstream package distributor has patched the library, and perhaps not changed the version to indicate that).
2. There are often multiple protocols for a given operating system feature. For example, back when I was a developer's egg, file-locking was done through three different protocols (at least): dotfile, lockf, and flock. It wasn't actually done this way ;-), but if there were a lock.so library, and all running processes used the same lock.so, nobody would step on anybody else's files. (Nowadays the OS provides "mandatory locks", solving this problem and introducing others.)
3. Particularly important are security protocols. We really really want all of your (new) processes to upgrade to the latest versions of TLS and the latest cipher suites. Upgrading your libssl.so makes all of that possible with one upgrade. Another example is the resolver for various name services (the one that GNU libc is so finicky about).
4. Some programs will try to load a shared object when an optional feature is requested, and gracefully fail if it's not found. Shared libraries allows the user to decide if they want to encruftify their system with that library.
[description of filesystem-based library management system omitted]
You've reinvented library versioning, except you're using the directory hierarchy as a database, rather than the .so version. I'm sure NixOS handles 1 and 2 above (eg, by using links to a common instance of a particular library version), and maybe 4 (though given the /opt philosophy, I suspect not). I have my doubts about 3 though (see below).
So you try the new version, it works.
I don't see how this differs from FHS-style organization, as long as you build RPM packages, which is best practice anyway. The only advantage of the "every configuration option is a file system path" approach that I can see is it makes doing things "by hand" or roll- your-own scripting easier. But by that same fact, you give up accessing all the experience that makes RPM a complex system, in particular, solving the problem of maintaining multiple versions of programs simultaneously. You may prefer doing it yourself, and that's fine; but then you won't be as happy with a Fedora (RHEL, Centos) system as *most* others are, and you're unlikely to convince them to change Fedora and friends.
If you want multiple versions of the application, sure, you have to do some fiddling, but that's easy enough with the same device: you attach a version string to the program's name. Even if the application's native build system doesn't allow that kind of configuration, RPM can help you with it, I believe, and if not of course you can script it.
If nobody use programA_version1, you can delete pkgs/programA_version1 and pkgs/libX_version1 now.
The process of removing unused library cruft works fine with package managers managing FHS systems with shared libraries mostly found in a single directory as well. Most (all?) libraries are on your Fedora system because some package you requested to be installed required them. If that package specifies a versioned dependency, that version of the library will be required. Once that package gets upgraded, that requirement will be removed. Once the last such requirement gets removed, so does the library. And you get all the benefits I described above.
Of course there's the problem that some package you want to build from source doesn't work correctly with the default (ie, most recent) version of the library on the system. Then you need to get the appropriate version, and make sure the application links to it. The least-effort way to do this is to write a spec file with the version dependency and use the system package manager to build and install a package, which then requires (and installs) the appropriate version of the library, because this is a common situation. Of course there's extra effort if you need to learn to write the spec file, but not that much extra effort. (If the library version doesn't exist in the package repository, of course you'll need to get and build that too, but that's true for both ways of organizing package installation.)
So in sum, (1) I really don't see what the problems you're worrying about are (except for the need to learn how Fedora handles those situations), and (2) there may be serious defects to per-package library management, such as enforcing system-wide conformance to recommended security protocols and encouraging maintainers to update their packages to use new versions of required libraries. I suspect that it's really difficult for a per-package hierarchy to discourage users from using old versions of libraries that are strongly deprecated due to security vulnerabilities and the like when the package maintainer (or user!) can just overwrite the link with an old library version (or a link to it!)
Steve
On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel < devel@lists.fedoraproject.org> 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.
No the FHS was decided in the late 90's and early 2000's to keep from the way that the Unix distros has split apart where things could be. In general some of the items were based off older layouts but there were differences between BSD unix and System V unix layouts also. Most of these differences were mainly meant to make it so you had to script or write for Irix or HPUX-5 or <<fill in version of SCO/Unixware/etc >> which made users, developers and administrators very hard to work on.
It was also to enforce things where you might find the distributor came with a /usr/local/.. which you couldnt replace or a /opt/<fill> which was different from another /opt etc. It was also written for a time when you had hundreds of users on a system and you wanted make sure that could get things running.
That said, it does limit some choices and layouts but it is mainly to avoid the splintering effects so that I don't have to write a FedEx aware program/script and a Nuix
On Fri, May 22, 2020 at 4:37 PM Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel devel@lists.fedoraproject.org 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.
No the FHS was decided in the late 90's and early 2000's to keep from the way that the Unix distros has split apart where things could be. In general some of the items were based off older layouts but there were differences between BSD unix and System V unix layouts also. Most of these differences were mainly meant to make it so you had to script or write for Irix or HPUX-5 or <<fill in version of SCO/Unixware/etc >> which made users, developers and administrators very hard to work on.
It was also critical to the "dump" and "restore" backup systems of the time, and bootstrapping new installations. It also helped segregate partitions and filesystems so that they could be sensibly split up for multiple disks, migrations to larger systems, and to allocate space for bulky bundles like, say, Oracle over in /opt/ to keep its binaries from replacing or getting confused with normal binaries of the same names.
Part of the problem since then is when people each decide not to pay any attention and invent their own schemes. Yes, I'm looking at you, "flatpak".
It was also to enforce things where you might find the distributor came with a /usr/local/.. which you couldnt replace or a /opt/<fill> which was different from another /opt etc. It was also written for a time when you had hundreds of users on a system and you wanted make sure that could get things running.
Dear lord, yes. Don't get me started on "/home/apache" for Debian and what it does to setting "/home" as an NFS mount.
That said, it does limit some choices and layouts but it is mainly to avoid the splintering effects so that I don't have to write a FedEx aware program/script and a Nuix
-- Stephen J Smoogen.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Sat, May 23, 2020 at 01:01:04PM +0200, Vít Ondruch wrote:
It would be possible to install individual RPMs into paths such as:
/pkgs/programA_version1 /pkgs/libX_version1 containsbut I wonder how would you imagine the glue above this structure to make the programA_version1 to use the libX_version1?
No need to "imagine" anything. Nix works that way: https://lwn.net/Articles/337677/
The answer lies in symlinks.
On Fri, 22 May 2020 at 21:07, Paul Dufresne via devel < devel@lists.fedoraproject.org> wrote: [..]
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.
That has nothing to do with FHS. Only thing which needs to be prepared for that is using not overlapping locations between version by package themeselve.
Working example on which you can peak: gtk2, gtk3 and gtk4.
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.
FHS has nothing to do with checking or guarantee consistency of the isntralled resources. That kind of duties are on the package management software shoulde. ++mistake
The other problem I had with NixOS, was the strange Nix syntax of packages.
"Strange" is term of "fuzzy logic". Exact values given by that type of logic on processed objects strictly depends on "reference point(s)/context". Many people (like me) do't see anything "strange" here because we are using FHS within context with which seems you are not fasmiliar :) ++mistake
kloczek
As this topic comes up, I think the issue is more related to cases where upstream is not willing to support FHS installation. PETSc [1] is one case, openfoam [2] is another example which is currently under review [3]. The issue is that derived projects get used to this case of installation, which then can lead to projects depending those to assume that they are not split in the FHS structure, and require e.g. some example files to configure correctly (SLEPc [4] does this during configure)
This leads to a lot of pain, trying to convince projects to not assume the package is installed the way upstream recommends, but the way some distro prefers.
On the other hand, we are not consistent - mpi binaries end up in /usr/lib64/$mpi/bin/ but headers are in /usr/include/$mpi-$arch/.
This parallel availability is solved with (environment) modules [5] but as already discussed with respect to modularity, that causes quickly an explosion of possibilities ...
[1] https://www.mcs.anl.gov/petsc/ [2] https://openfoam.com/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=1816301 [4] https://slepc.upv.es/ [5] https://en.wikipedia.org/wiki/Environment_Modules_(software)
-
David Schwörer -
Nico Kadel-Garcia -
Parker Gibson -
Paul Dufresne -
Petr Pisar -
Przemek Klosowski -
Stephen J. Turnbull -
Stephen John Smoogen -
Tomasz Kłoczko -
Tomasz Torcz -
Vít Ondruch