On Fri, 22 May 2020 at 21:07, Paul Dufresne via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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@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
