(03-21-2022, 09:11 PM)Ofnuts Wrote: In traditional Linux, packages use dynamic and shared libraries libraries. This means that instead of giving you a huge executable where the code to load a PNG is included, you get a much smaller executable that will load libpng on startup. Of course, this software may have minimum requirements on the libpng version while other software is unfortunately hit by a bug that only appears in recent libpng. These incompatibilities can sometimes be worked around, but mostly it is the job of a "distribution" to provide you with mutually compatible applications. When you start updating these apps by yourself, things can get complicated, but that doesn't mean there is any kind of malice/malevolence anywhere.
I believe what is commonly referred to as as "lib" file in Linux, is what we called a "Dynamic Link Library" (DLL for short) in the old school
And I recall fits of what we called "DLL heII" where one program required a particular edition of a specific DLL, while the rest of your system expected another. Usually a renegade share ware developer with some new whiz-bang feature that required the new DLL, if I recall properly.And, they (the DLL model) make perfect sense where you have multiple programs having similar requirements, I understand and respect that need. Especially back in the day where hard drive space was precious. (In fact the idea of a "flat pack" to me seems to fly in the face of said imperative for efficiency, but today hard drive space is plentiful and cheap, so the flat pak model appears worthwhile in order to avoid the "grabbies" of one software product, vs the other.)
But I really believe there is more to it that just a couple libraries in this butting of heads between inkscape and krita.
Just to elaborate, and expose:
On a system having the earlier version mentioned above of inkscape already resident. Krita 4.4.2 and 4.4.8 will install with no problem whatsoever, with full functionality. And Krita 5.0.2 will install and work, sans Gmic
However, if I first update Inkscape to the above referenced level, while the updated inkscape works just fine, any attempt by me to thereafter install any version of Krita, is met with a "broken packages" refusal to proceed.
And I got to thinking last night of how I've conditioned myself to update certain programs in a particular order, versus another program, to avoid issues.
And so I decided to install Krita before updating Inkscape...... And THAT worked...no broken packages...and Both programs worked thereafter
EXCEPT....Having forced the Krita install at version 4.4.2 in order to maintain Gmic functionality, the later update to inkscape forced an update of Krita to the latest version...drats! When I saw the "5.0.2" on the Krita splash screen, my heart just sunk.
So, just for good measure, I repeated the entire exercise from scratch, this time sifting carefully through the menu of things to be changed by the Inkscape update, and sure enough there was a
To be Installed:
Krita 5.0.2
Krita-data 5.0.2
^^^ listing for the "work to be performed". This was no swapping out of a couple linked libraries...it was a wholesale replacement of the entire installed version, lock stock, and barrel. And perhaps most regrettable, no options such as "would you like to upgrade Krita?"
Curious to me that the Inkscape update proceeded fine with Krita not present on the system, so one would suspect there was no cross dependency? But, only with a version of Krita already present, does the Inkscape update demand the wholesale replacement of Krita with the newest version.
It's challenging to see this as anything other than a determination of one producer to NOT stay in their own lane. Perhaps this is one area where copyrights unintentionally protect the end user from "creative developers"?
And, I'm quite sure that either developer would be more than willing to give me a full refund?
The end result has only forced me into a small compromise in determining which is of greater use to me, gmic under krita, or an updated Inkscape....so its really more of a learning experience for me than it is any catastrophe.
But, it did get me to thinking "Hey, I bet this is why those guys advocate flat paks?"
Thanks to both of you for your replies
But, I guess if I start using flat paks, I'm gonna have to start editing my path statement, manually?
Fairly straight forward procedure under OS/2 in the config.sys file. Perhaps more covert under Linux?