Re: The price of FHS
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 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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 signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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
Re: The price of FHS
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 -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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 contains > > ~~~ > > but 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. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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-le...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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 > 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-le...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
On Fri, May 22, 2020 at 4:37 PM Stephen John Smoogen wrote: > > > > On Fri, 22 May 2020 at 15:59, Paul Dufresne via devel > 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 > <> 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/ 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-le...@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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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-le...@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
Re: The price of FHS
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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 <> 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/ 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 -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
Re: The price of FHS
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 > 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-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List
