12 ms·
The "competing pkg-manager" issue is still unsolved. Rarely does it makes sense to manage libraries centrally in a distro if all the developers of the language
by ysleepy 5y ago
The "competing pkg-manager" issue is still unsolved.
Rarely does it makes sense to manage libraries centrally in a distro if all the developers of the language ecosystem use their own package manager.
I develop java and I never even had the idea to get dependencies through my distro.
If there is zero buy in from the devs, all the work of integrating the central managed lib classpath is on the port/package maintainer.
I think most of npm/mvncentral/cargo/pypi/go+git/cpan/rubyforge don't have distro packages.
The work is very valuable for the user facing applications, but I have trouble seeing it continue apart from essentially treating it like statically linked binaries and automate more based on that.
- rwmj 5y agoI don't want to have to manage N different package managers. I want one that keeps all the packages up to date and applies security updates. Not the mention the problem that some packages depend on multiple language ecosystems, and the separate "managers" can't even begin to cope with that.
- bzzzt 5y agoThe problem is Java packages are converged around the Maven central repository which is not compatible with the RPM way of doing things. (it's a packaging mess somewhat halfway between RPM and NodeJS...) Since most Java developers use something other than an RPM based packaging system (hey, it runs anywhere ;) they simply don't care about it which pushes the impossible job of creating native packages for 2,5 million Maven central packages to a maintainer. You don't need a maintainer to fix that mess, you need an army or accept sometimes it's more opportunistic to use soms non-native technology.