+- Gimp-Forum.net (https://www.gimp-forum.net)
+-- Forum: GIMP (https://www.gimp-forum.net/Forum-GIMP)
+--- Forum: Other graphics software (https://www.gimp-forum.net/Forum-Other-graphics-software)
+--- Thread: Predatory Software? (/Thread-Predatory-Software)
Predatory Software? - rickk - 03-21-2022
Over the past several months, I've grown amused over how updates for one program can adversely impact another.
Especially in context with internet browsers Firefox, Chromium, and Konqueror. Won't go into specifics there because I appreciate this is not the place for "that", other than to say I've been watching a ping pong game where updates to "A" introduce problems to "B", breaking specific functionality...which inspires a fix, that in turn the fix to "B" wreaks havoc upon "A", and the cycle repeats.
I guess that "independence" of the open source model has it's own unfortunate consequences?
Specific to graphics software. I've been installing on separate machines, various vintages of Krita, versions 4.4.2. 4.4.8, and 5.0.2 without major difficulty ( other than the Gmic issue with 5.0.2)
When installing those,... I always notice a transaction listing claiming to remove an inkscape file. evidently it replaces said file with an updated equivalent, because my old inkscape app continues to function.
However just this past weekend, I noticed that an update for inkscape was being offered. I believe the update was from my original install of version 1.0.2-3 to a new offering of 1.1.2-3+b1
So, I updated Inkscape, and thereafter the synaptic package manager refused to install Krita (any vintage) on my machine, citing that I must fix broken packages, before proceeding.
So, clearly the inkscape update fluxxored my system in some way to prohibit the install of Krita (on new media that had never previously had Krita as a resident program)
And attempts to fix broken packages were stonewalled. I eventually ended up having to reformat, and do a completely fresh install, forgoing the update to inkscape in order to install Krita 4.4.2 Which worked fine
But my questions, is this type of conflict between programs common place? Is this the reason many of you have become advocates of "flat paks" and "AppImages"....to put an end to such hijinks? I think I'm about to become a believer
RE: Predatory Software? - rich2005 - 03-21-2022
You probably will have to become a flatpak believer above all.
I set up a ubuntu 22.04 VM to see what in the Gimp line works.
Installing Gimp easy enough, "apt install gimp" gets a Gimp 2.10.30 but no python.
Do the old gimp-python packages work with 22.04 ? You can install python2.7 but python-is-python2 missing. The gimp-python packages break other packages python-cairo missing python-gtk missing, use old packages more broken packages.
Your friend here is "apt --fix-broken install" which generally uninstalls the broken packages
Thought I would try an appimage, I do not need the latest and greatest Gimp, just something that uses python plugins. No good as a portable app. The appimage rockridge file system uses fuse2, now deprecated in favour of fuse3 (same as python2 / python3). I did get the Gimp appimage running by unpacking it (the --appimage-extract switch). Python works but not the gmic_gimp_qt plugin, more incompatible lib files. Gave up for the time being.
RE: Predatory Software? - Ofnuts - 03-21-2022
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.
RE: Predatory Software? - rickk - 03-22-2022
(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?
RE: Predatory Software? - rickk - 03-22-2022
(03-21-2022, 08:32 PM)rich2005 Wrote: Your friend here is "apt --fix-broken install" which generally uninstalls the broken packages
Thanks for "that". I anticipate that will come in very handy in a "break glass in case of emergency" sort of way.
RE: Predatory Software? - rickk - 03-25-2022
Just as a general observation, I believe that software that installs "unintended" extras on your machine, even semi covertly, is regarded to be "malware". Even in the absence of malicious intent.
Wasn't there a big stink several years ago over browser plug ins and extensions that discreetly imported unspecified "features" as part of their base installations?