Hacker News new | past | comments | ask | show | jobs | submit login

It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies. Even Node's package manager supports that. The end result is that rolling release distros break stuff often, as applications can't be tested and executed in isolation of each other. The "solution" to this is releasing everything every 6 months, when you can actually test everything together, then stop providing new versions for months.

If Linux/Linux distributions did support it, rolling release would be a lot more common. One limitation that would remain is that if you have an application that requires a single instance (e.g. a Network Manager), you couldn't have multiple instances of it running at the same time.




This is insanely important.

The goal of an operating system is to run applications. The installation and packaging of software should be as simple as possible.

For whatever reason, the Linux desktop community does not see this as an issue.

If I want Vim 7.4, 7.3 and 7.1 installed at the sametime, your package manager should support it. What if 'X' plugin is only compatible with 7.1 and 'Y' plugin is only compatible with 7.4. This is a valid use case.

Lately, I have been using Docker to work around this, but it's not fun setting up GUI applications in a container.


Well (I think) part of the whole point of a package manager is to reduce space by sharing dependencies. Npm seems to actually store a copy of the dependency individually for each package that requires it. I really think that is inefficient and a step backwards.


A good package manager should allow to: -share dependencies -provide a way to install multiple versions of the same package

These requirements are not mutually exclusive. With a proper file system hierarchy both of them could be accomplished.

Most of the popular distribution's package managers (apt, pacman, etc) support the sharing dependencies but almost none of them support installing multiple versions of the package.

Given that storage space is very cheap nowadays I think a package manager like NPM which stores copies of the dependencies is not that bad actually.


This is where most Linux package managers do a really good job.

However, the system should be designed in a manner where I have a choice.

This here: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Makes no sense in a world of dynamically linked libraries and 6 month release cycles.


Yes, npm uses more space than what is necessary, but luckily disk space is cheap. That said, npm does optimize the disk space usage a bit. If I have package A which depends on packages B and C, both of which need D, then (if the versions match), D will be installed only once.


> Even Node's package manager supports [parallel versions of dependencies]

I feel like your emphasis is backwards.

It's not surprising that NodeJS, a new project, has solved some of these problems. NPM has the luxury of decades of experience from dozens of linux package managers and package managers from other languages. Plus, they're not tied to the legacy use cases the same way that (e.g.) apt is.


Do you have a link that would educate me about some of these problems? Package management interests me because I might find myself developing a package manager in the near future, but I don't know much about it.

Not supporting multiple versions of the same software is something that I identified as a problem though.


I don't recommend developing a package manager until you have done a lot of research. Its a field with non trivial problems and a lot of existing experience, and a lot of implementations that may well solve your issues.


You might be interested in Nix: The purely functional package manager [0]

[0] - https://nixos.org/nix/


I don't think it's surprising either, I just hope that Linux will solve the problem too. I guess I used the 'even' rhetoric because if Node could solve it, Linux (a much larger and better financed software ecosystem) should too.


> It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies.

They do and they have, but they can't conjure-up libraries that haven't been properly versioned and released upstream.

If the GTK+ team can't maintain an ABI then they need to start releasing versions under different sonames such that programs like wireshark link against "libgtk-3.so.0.1200.2" and not "libgtk-3.so.0", then the package managers will be able to do the right thing.


Some Linux distributions have no problems with multiple versions of parallel dependencies. Gentoo, for example.


"It's unfortunate that Linux and/or Linux distributions have not yet solved the problem of supporting parallel versions of dependencies."

Uh, they have. For ever.

I have parts of boost 1.49, 1.53, 1.54 and 1.55 together on my system. I have GTK2 and GTK3 together on my system. I have Qt3, Qt4 and Qt5 together on my system. Python2 and Python3. libpoppler19, libpoppler44 and libpoppler46.


Which distribution supports it in general? Sure, there are particular instances of it being supported, but it's not supported in general.


This is under Debian, running Stable (Wheezy) by default, but with some selected packages from backports and Testing (Jessie).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: