Products > Programming

Linux Dependency Black Hole

(1/11) > >>

mag_therm:
I used  linux in engineering for 15 years , now I am hobby user in ham radio.
When installing applications, I recall only a few issues in prior years, but after about 2020, the dependency issues started to escalate.

This year I have been installing Software Defined Radio applications with lots of dependency problems, and this week I had to abandon attempts to install
the NXP MCUX IDE on Fedora due to inability to resolve wrong/missing dependencies. And over on the HamRadio section, Metrologist has just documented the output while tryng to install a ham radio application on a debian Pi.
Engineering software for industrial use needs a lifetime of over 15 years, Similarly ham radio sdr software followed the surge of hardware development back around 2014, still current.

I would like to ask a few questions to improve  understanding of how and why dependencies became a problem for users trying to install applications.

1A). When a dependency itself is updated,is it normal/allowable for the original/prior functionality af that utility to be removed?
   That is if a function was previously called with a set of args, and then gives an output, why can't that functionality be retained "forever" along
    with the new additions which come out with a new version number appended to the dependency filename. ?
   Examples that do work "forever" are like the bash utilities, and sqlite stty etc. Why can't the libs be more like that?
   If back compatibility could be made a rule, it would take away 80% of dependency failures, in my experience.

1B). Conversely why does the app installer not throw a warning and proceed anyway to use the updated lib that it finds ?
   In my experience on Fedora , rolling back a dependency is difficult, and also can disable applications already installed.

2).Sometimes when installing a missing dependency, I see it is just a few kB or MB. Why would the App developer not include such small functions into the app?

3). Python3. I am fairly sure that Python 3 versions have always retained ability to run deprecated functions. So why would an app want a specific Python3?

4). Paths: I saw on Fedora that system paths do change over the years. The simple way for a user to fix a "can't find" would be to find and export the PATH or lib LD..  path.
Why can't the app installer be doing a check of the system paths before throwing a "can't find"?
   An example was that NXP app MCUXpresso say just "Can't find Python3.8" doesn't say the path it used. When I installed it in ~/.penv and exported that       path, still ""Can't find Python3.8"

 The way this is going, I can see that soon, we will have to install apps on their dedicated complete o/.s
 And that is what I am now trying to be able to solve present problem.

ataradov:

--- Quote from: mag_therm on April 24, 2024, 03:53:05 pm ---1A). When a dependency itself is updated,is it normal/allowable for the original/prior functionality af that utility to be removed?

--- End quote ---
If the major version of the library changes, then entire API may be different.

A good example here is libusb. Version 1 and version 2 of the library use entirely different approach to the API. They did not change it "just because", they changed it to support higher performance.
Maintaining APIs forever is a lot of work and nobody wants to do it for free.


--- Quote from: mag_therm on April 24, 2024, 03:53:05 pm ---   If back compatibility could be made a rule, it would take away 80% of dependency failures, in my experience.

--- End quote ---
Are you willing to pay for it?



--- Quote from: mag_therm on April 24, 2024, 03:53:05 pm ---1B). Conversely why does the app installer not throw a warning and proceed anyway to use the updated lib that it finds ?
   In my experience on Fedora , rolling back a dependency is difficult, and also can disable applications already installed.

--- End quote ---
Major versions of the libraries are usually not installed automatically. And multiple major versions can usually coexist. Minor versions rarely break APIs. And when they do, it is not on purpose.

Sometimes things break because application authors used undocumented APIs. And this is on the application authors.


--- Quote from: mag_therm on April 24, 2024, 03:53:05 pm ---2).Sometimes when installing a missing dependency, I see it is just a few kB or MB. Why would the App developer not include such small functions into the app?

--- End quote ---
Because then you will have to maintain the code. Plus sometimes there are license restrictions.


--- Quote from: mag_therm on April 24, 2024, 03:53:05 pm ---3). Python3. I am fairly sure that Python 3 versions have always retained ability to run deprecated functions. So why would an app want a specific Python3?

--- End quote ---
Likely because the app is written poorly.


--- Quote from: mag_therm on April 24, 2024, 03:53:05 pm ---   An example was that NXP app MCUXpresso say just "Can't find Python3.8"

--- End quote ---
MCUXpresso is a cost center for NXP, not a profit center. It gets corresponding amount of attention. All vendor tools from all IC vendors are bad. They cost money and don't directly contribute to profits. As long as they mostly work, it is fine. FPGA IDEs are some of the worst software ever created. Yet there are no alternatives and what are you going to do? Not use that FPGA?

Your questions are too abstract and actual details would not be universal and would depend on the specific cases.

coppice:
The current version of the ITU G.1050 spec is at https://www.itu.int/rec/T-REC-G.1050-201607-I/en . Its from 2016. Not exactly new, but not exactly ancient. Try using the software provided there. It requires numerous things, mostly open source, but it requires specific revisions of many of those things. It looks like within 2 years of the publication of that spec you couldn't find some of the necessary versions on the internet, and now you can find almost none. So much for the notion that with open source you just publish and somewhere on the internet it will be effectively archived. :)

Demanding too much backwards compatibility is a bad thing. You learn a lot about how to design something well by getting a first weak pass out the door. If you can't be incompatible you are locking in a lousy design forever. You do need to keep the old stuff relevant for a very long time, though. ataradov referenced libusb totally breaking compatibility. gstreamer and other software has been through the same thing. Some of those things struggled to move people on to the better solution, but that did discipline them to keep the old version usable and relevant. Many people are too keen to let the old stuff rot when they are able to carry a good number of people forward to the new version.

ataradov:
I find it hard to complain and demand people keep the old stuff up to date given that all those things are developed for free. Bigger projects like Gstreamer have some monetary support, but smaller libraries don't. Even though they are often at the foundation of everything. And even when there is monetary support, people allocating the money usually have some influence on how it is spent, and rarely there is incentive to spend it on keeping the old stuff up to date.

If anything, a more reasonable demand is to have the applications that use those libraries be kept up to date. It is strange to ask authors of the libraries to do more work because you don't want to do the work yourself.

mag_therm:
Thanks ataradov and coppice
Yes I understand this is all FOSS. I support linux and FOSS and believe the concept has been of significant benefit over the years.
DSP is an outstanding example in my area of interest, another is image processing.

I am pointing out that the problems with linux dependencies is getting worse, to the level of "reasonable" users not being able to install,
and asking why.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod