[opensuse] multi-distro-release compatibilty (was Re: Okular - Please put Adobe Reader back in)
Knurpht-openSUSE wrote:
Anyway, this definitely is not an openSUSE problem**, the project has no way to change this, unless Adobe open sources the code, which is, given their statements in the past, not going to happen
** MS adopted this problem and decided it was their responsibility. At first they worked on solving 'DLL-hell' in XP, and by Vista+Win7, they'd pretty much solved that with side-by-side libraries (keeping old dynamic libs and loading the correct one for each app loaded). Later they added a special daemon ("Application Experience") to create a load-time environment around apps to support more complex cases. Distros and linux-run-time(gnu) is mostly going the other direction -- specifically adding features that are more likely to disallow apps not built specifically for a specific distribution. To support these apps, it would simply be a matter of saving their dependency-libs and not deleting old libs when adding new ones. It would also involve bumping the 'so#' on libraries when interfaces change, and not distributing files of the same name with different internal apis (internal symbol versioning). Basically linux is moving away from the model that has allowed MS to dominate the market and that will marginalize and eventually kill off any chance of linux being a competing platform. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/29/2018 08:41 PM, L A Walsh wrote:
Distros and linux-run-time(gnu) is mostly going the other direction -- specifically adding features that are more likely to disallow apps not built specifically for a specific distribution.
Some of this we do to ourselves with the glibc and gcc improvements, other libs like libpng, etc.. Many times the things that are done are done for security reasons like making the png structure opaque. This automatically breaks backwards library compatibility -- and it done for security reasons, it doesn't make a whole lot of sense to provide continued backwards compatibility. But then in the same breath we do it anyways with libpng12, libpng14, etc... Now this isn't directly to your point, but it is a close tangent. While you can compile code to support the different library implementations at compile time, it is more difficult to do are run time (mostly due to LSB turning into more a goal than a standard making the standard library search paths more a guessing game, and each distros slight variation on library naming conversions -- though softlinks could take care of some of that, if everyone could agree on a standard name for each library). The -lname is consistent at compile time, but beyond that unless a standard symlink name is agreed upon, it's tough to search of the latest or specific version of anything. There is no reason it can't be done (not for every package, but for those where there is code compatibility across different versions of a library) I would just take more standardization of the practice across those coding for Linux. In an open-source world of contributed code, that is one difficulty that is posed. Sonames have worked but with frustrating hiccups. A current prime example is ncurses5/6 which has caused a bit of growing pain. I don't have an answer, but I could see things improving if library search and install paths along with naming standardization (or at least a set of standard named symlinks) were agreed upon. Most of the major packages at least adhere to some sane standard, but the other 95% of Linux software contributed the the average Joe has little if no standardization other than what is enforced by the compiler or package manger. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
David C. Rankin -
L A Walsh