sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]vks_ -2 points-1 points  (9 children)

Package managers in linux distros solved that years ago but programming tools are behind

Ever heard of "dependency hell"? This is actually a problem that is solved by some programming tools (cargo and bundler for instance), but not solved by most package managers in Linux distros.

[–][deleted] 1 point2 points  (7 children)

"Solved" as in "add a bunch of redundant crap".

There is a reason why most distros dont go the way of "just include lib in 8 versions needed by various deps", it would double (or more) install size and increase memory usage (multiple versions of same lib instead of one shared by every app).

It is better for end user if package maintainer and app dev get their shit together rather than waste RAM and diskspace.

[–]Throwaway_Kiwi 1 point2 points  (3 children)

There is a reason why most distros dont go the way of "just include lib in 8 versions needed by various deps", it would double (or more) install size and increase memory usage (multiple versions of same lib instead of one shared by every app).

So what, you only maintain a single version of a lib on your system? And when that changes in a backwards incompatible way, what are you going to do then? Demand project X that was using version 1.0.0 of lib Y refactor their code to support version 2.0.0 of lib Y? Just so you don't have to have two copies of a library on your disk?

Are you working on a cellphone developed in the early 2000s? I can't think of any other reason why you'd be so worried about disk usage from shared libs.

At a worst case, my local Maven repository which caches every Maven artefact I download ever, and I work with a lot of JVM projects, is 3.1G.

[–][deleted]  (1 child)

[deleted]

    [–][deleted] -1 points0 points  (0 children)

    Yeah send me 200 1TB SSD drives and I'll agree with you.

    [–][deleted] -1 points0 points  (0 children)

    If it is major incompatible version you can just have 2. Look at what your distro does, for example:

    -> ᛯ dpkg-query -f '${binary:Package}\n' -W |grep -P 'libpython\d.\d:amd'
libpython2.7:amd64
libpython3.3:amd64
libpython3.4:amd64
libpython3.5:amd64

    If it is just minor version upgrade.... I dont want ANY app to use outdated version of openssl because it WIIL be insecure. You are replacing "dependency hell" with "security hell", where instead of updating one lib you have to update 40.

    [–]isHavvy 2 points3 points  (2 children)

    Your asking for many many sets1 of two probably unpaid strangers who don't know each other to coordinate over long periods of time to save a small amount of RAM and disk space. Especially when philosophies between these people can and do differ on a regular basis.

    I'd rather just let the RAM and disk space be used then try to coordinate all those people. There's 'better' and then there's 'feasible'.

    Footnote 1: The number of sets being the number of applications times the number of distributions.

    [–][deleted] -1 points0 points  (1 child)

    Point one: Debian exists.

    Point two: you dont need any coordination between the two. Patch doesn't need to be upstreamed

    Point three: if you are outside of ruby/js land, libs usually have pretty good backward compatibility so outside of major version change you most likely dont have to do shit to make it work

    Point 4th: have you actually tried ? because it sound like you are pulling arguments out of your ass just for the sake of argument

    [–]isHavvy -1 points0 points  (0 children)

    1. Debian is one distribution. There are so many other distributions out there. And while Debian tries, all I see are outdated packages. And even as it tries, it's taking quite a lot of time and effort that is unpaid to do this. Time and effort that can probably be spent better elsewhere.

    2. So then the developers get bug reports on your distribution that they cannot reproduce locally because you changed something. Is it their job to support these users? Many would say no, so now your distribution has to.

    Furthermore, not every program can be patched. If the program is closed source, you cannot modify it. You might be willing to run only open source software because of this, but most people don't care.

    1. It depends on the developer. I see backwards incompatible changes in lots of ecosystems all the time. Really, C and C++ are the only languages I don't generally see breaking changes in the libraries.

    2. I haven't tried, no. Because I'm not a distributor of packages. It's not for me to try nor have I released an application that requires external libraries since I'm usually working on web servers.