You are not logged in.

#1 2014-04-20 15:15:15

Vesa P.
Member
Registered: 2014-04-20
Posts: 13

Dependency problems, parallel library environments?

Hi,

I've noticed that package dependency problems are a significant hindrance to the basic freedom to install any software of choice into your computer. In some case(s) this has made it easier to run the Windows version of a program with WINE than to get the native Linux version up and running... which is, of course, embarrassing.

Does Arch offer any particular solution to this problem?

The known solution is to establish a (partly) segregated library environment in one way or another. Probably the simplest way (when sufficient) is by putting the "foreign" application into a directory together with its special needed libraries and running it with "LD_LIBRARY_PATH=." before the program name so that the libraries in the same directory take precedence to default libraries with same names. A more complicated alternative is by making a chroot sandbox for the application. Are there other solutions?

Of the solutions above I've only tried the "single directory with LD_LIBRARY_PATH=.". The problem with that was that I had to satisfy library dependencies one by one (on an Edubuntu installation), and there were painfully many of them. Maybe a chroot solution or some other solution would allow you to use the automatic dependency solving capabilities of a package manager to fill in the missing pieces?


Any experiences, ideas?   I think this is a problem that should be properly solved in order for Linux freedom to really flourish.

Regards,
Vesa

Offline

#2 2014-04-21 08:46:26

sonoran
Member
From: sonoran desert
Registered: 2009-01-12
Posts: 192

Re: Dependency problems, parallel library environments?

Offline

#3 2014-04-21 16:04:42

Vesa P.
Member
Registered: 2014-04-20
Posts: 13

Re: Dependency problems, parallel library environments?

Thank you!   That Software Collections concept goes right into the point. Now I have some material to study...

Offline

#4 2014-04-21 16:34:16

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: Dependency problems, parallel library environments?

Vesa P. wrote:

Hi,

I've noticed that package dependency problems are a significant hindrance to the basic freedom to install any software of choice

Example?

Vesa P. wrote:

Does Arch offer any particular solution to this problem?

Actually, common sense offers the best solution - avoid this "problem" altogether by not using proprietary pre-compiled crap applications. Use the packages that are lovingly prepared for you by the Arch devs and TUs, or if the repos do not have what you want, create your own package compiled against the current versions of all required libs.

Offline

#5 2014-04-21 20:45:46

Vesa P.
Member
Registered: 2014-04-20
Posts: 13

Re: Dependency problems, parallel library environments?

tomk wrote:
Vesa P. wrote:

Hi,

I've noticed that package dependency problems are a significant hindrance to the basic freedom to install any software of choice

Example?

Well, if you just find some nice program for Linux in the 'net, library incompatibilities may well prevent you from just (compiling and) installing it on your system... or at least make it an arduous task.

Then there are the cases where you want to retain an old version of a program because the developers are taking the program to a direction that runs contrary to your needs.

Then there are the closed-source programs which you seem to loathe... There are cases where a program operates as a client to a commercial service and cannot practically be open source because of competition (and maybe other reasons). In those cases I really appreciate when some service provider provides a client not only for Windows but also for Linux, even if it is closed-source.  And so I'm not convinced that open source can meet every need in the kind of world we live in but I think a general-purpose operating system for home use or whatever use should also be workable as a platform for commercial software.

Offline

#6 2014-04-21 21:21:33

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: Dependency problems, parallel library environments?

Vesa P. wrote:

Well, if you just find some nice program for Linux in the 'net, library incompatibilities may well prevent you from just (compiling and) installing it on your system... or at least make it an arduous task.

Hate repeating myself, but.... example? smile

Vesa P. wrote:

Then there are the cases where you want to retain an old version of a program because the developers are taking the program to a direction that runs contrary to your needs.

You could fork it - that way you could keep it the way you like it but still make sure it builds against current libs.

Vesa P. wrote:

I think a general-purpose operating system for home use or whatever use should also be workable as a platform for commercial software.

There are quite a few distros out there that would support a similar philosophy - unfortunately for you, Arch most definitely does not.

Offline

#7 2014-04-24 11:55:48

Vesa P.
Member
Registered: 2014-04-20
Posts: 13

Re: Dependency problems, parallel library environments?

tomk wrote:
Vesa P. wrote:

Well, if you just find some nice program for Linux in the 'net, library incompatibilities may well prevent you from just (compiling and) installing it on your system... or at least make it an arduous task.

Hate repeating myself, but.... example? smile

Vesa P. wrote:

Then there are the cases where you want to retain an old version of a program because the developers are taking the program to a direction that runs contrary to your needs.

You could fork it - that way you could keep it the way you like it but still make sure it builds against current libs.

Yes but it would require you to
  (1) study and gain sufficient understading of the source code (to)
  (2) find the root causes of the problems and solve them (and to)
  (3) keep solving problems and making changes to the codebase as the packages of your system get updated.

That is the point where your fundamental freedom or right to be the lord over your own computer gets violated: Other people change libraries and force you to drudge/work just to keep your system workable.
    That is the problem I was trying to find a solution for: How to give YOU the power to decide about your environment and environments for different applications as needed, avoiding disturbances caused by other people's desires and decisions to change libraries and packages.

---

You insisted for an example; originally it was vs. my statement "I've noticed that package dependency problems are a significant hindrance to the basic freedom to install any software of choice.".
    I don't have a precise and timely example that you could go and verify or refute, but here's something: When my current distro (Ubuntu/Edubuntu) dropped support of Tux Racer, changing it for Extreme Tux Racer (if I remember correctly), I set up tuxracer.exe via WINE because other ways to install Tux Racer seemed more problematic.

Offline

#8 2014-04-24 12:15:29

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

Re: Dependency problems, parallel library environments?

avoiding disturbances caused by other people's desires and decisions to change libraries and packages.

It seems to me that any update could have that effect, so the only way to be sure of that is to never update anything.
You might come close to that if you were to use a RHEL version that has entered Extended Life Phase, see https://access.redhat.com/site/support/ … es/errata/ .


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#9 2014-04-27 16:42:33

Vesa P.
Member
Registered: 2014-04-20
Posts: 13

Re: Dependency problems, parallel library environments?

Lone_Wolf wrote:

avoiding disturbances caused by other people's desires and decisions to change libraries and packages.

It seems to me that any update could have that effect, so the only way to be sure of that is to never update anything.
You might come close to that if you were to use a RHEL version that has entered Extended Life Phase, see https://access.redhat.com/site/support/ … es/errata/ .

In practice you usually want/need new versions in some things and stability in others in the same installation if possible, and so some separation of application environments may be useful. But I guess this is enough of this topic here.

Offline

Board footer

Powered by FluxBB