18 Feb
2021
18 Feb
'21
10:54
середа, 17 лютого 2021 р. 00:08:01 EET L A Walsh написано:
This is another example of a snapshot that will make
package
upgrades impossible w/o a full rebuild -- for a similar reason
rpm 4.15 can't be built by rpm 4.14 or before. rpm 4.11 ships
with rpmlibs-v3, while rpm4.15 ships rpmlibs-v9. The libs
jumped 6 versions while rpm went up 0.14.
The windows of what binaries work with what date of TW
is too small.
How is this connected to binaries? I have quite old (about 5 years)
proprietary program which was built on/for CentOS 7 (not new OS either) and it
works fine on TW (have checked before transiting our server to Leap).
While some may think I have uniq problems, the
intra-distro binaries
are going to have more and more of these cases. It's not a workable
situation.
I can take programs in Win from 10-20 years ago and they still work
on a current day win because the OS loads library updates by version.
Unix did the same -- but move to linux, and vendors got lazy and stopped
using the correct versions to link with.
Why? And how can this be fixed?
As for Windows, same for Linux, if program supposed to work on wide variety of
systems, you provide it with all libraries it needs with minimal dependency on
system libraries. Windows have no standard way of dependencies so every app
HAVE TO drag all stuff with it. WinSxS is a way to keep all that stuff in a
non-controversial form (and reduce duplication in theory, though in practice
it still keeps a bunch of different versions of the same library because they
are slightly different), it doesn't provide dependencies for you.
In Linux you could do the same, but most proprietary packagers prefer either
static builds or bundle everything, because implementing this stuff in proper
way needs a normal repository with at least RPM/DEB structure.
For some time there is a FlatPak to solve this problem, which has its own
packaging format, repositories and dependencies. While I'm not a fan of it (as
it has disk/RAM overhead) but it is a solution to not duplicate efforts for
developers.
As for open-source packages, keeping binary compatibility is not needed, it's
simpler to rebuild packages against new library and get rid of code
duplication.
--
Kind regards,
Mykola Krachkovsky
--
Найкращі побажання,
Микола Крачковський