> On 2021-01-31, at 19:20, Michael Orlitzky <[email protected]> wrote: > > The only thing a package manager does for you is that it allows one > person (the Gentoo developer, in this case) to invest a little bit of > time to save everyone else (the Gentoo users) a lot of time. When > software has been packaged correctly, it integrates well with the rest > of the system, gets constant maintenance and security updates, and can > be managed from a central location in a consistent manner. > > "Packaging" software like you describe isn't packaging it in this > sense.
It still results in the convenience of having Portage as opposed to something else manage system files (files not in /home). It gives a consistent way of deploying the software on machines with the same distro or package manager. > When you bundle everything together, > > 1. Nothing is shared between packages so build time and disk > usage skyrockets. This is NodeJS and 99% of stuff is plain JavaScript. Many packages are tiny. More time will be spent unpacking tiny distfiles and re-arranging them the way Node/Yarn/etc like to see them. In Rust and Go, with Portage the distfiles are deduplicated as much as possible. But it's highly likely that one would have (Rust) random-1.0.crate and random-1.1.crate in distfiles because two packages need different versions. Wasteful? Yes except when those two packages are really necessary. > > 2. The number of updates and thus the amount of work required > > also skyrockets, for the same reason: when nothing is shared, you > > have to update each package whenever a dependency of a dependency > > of a dependency... changes. I'm not sure what you are referring to here. I was saying in my previous message that NPM's dependency issues is what makes most Node packages (IMHO) infeasible for something like Portage. We have smaller scale versions of this, with less conflicts: Python and Perl. They have thousands of packages but are shared decently, and generally easily patched to reduce the need for slotting. Node, even without conflicts, would be like this but would have a lot more packages. Would Portage actually scale well to this? It's not really known. > > 3. There are no security updates, ever. If you use anything written > in Rust or Go on Gentoo, or if you use anything that uses > anything written in Rust or Go, or..... it will NEVER get a > security update. No one even bothers looking for security > issues in these languages because the "find a bug then fix it" > algorithm is infeasible. I'm also not sure what you mean here. Docker is written in Go primarily and gets security updates just fine. It is one of the larger players in the Go world but still. Then of course on the Rust side, Mozilla is highly concerned with security (although their firing of most of the Rust team brings up questions). > > 4. You do get to do updates with e.g. "emerge -puDN @world", but not > really, because no one is actually updating Gentoo packages every > time a dependency of a dependency changes. That's because for Go, the most important thing is the binary. It doesn't have a concept of shared libraries. What goes into a Go binary is the latest version of its own code and the acceptable version of the dependencies. All .go source files, no libs. Rust does have libraries, but Gentoo has decided not to deal with them yet. As a result, Rust and Go are treated similarly in ebuilds. Crates can be libs, and used dynamically, but they do not have to be. https://doc.rust-lang.org/reference/linkage.html In the Node world, the equivalent to Go's bin is the main script executable, which usually people install with `npm -g` or `yarn -g`. Nobody would install a library like is-boolean globally because it has no real purpose on its own without something (the main script) using it. This may seem strange if you like to install libraries and then open the interpreter to play with it, but I mainly see this in the context of a project that has the node_modules/ directory in it, not with user-globally installed libs (the ones in ~/.node/). > > So ultimately, there's little benefit and it introduces security > vulnerabilities to our users who might be better off just using NPM or > whatever (or using software written in a sane language). I don't think it introduces security vulnerabilities more than any other new system, but it's very difficult to implement. It needs actual purpose (in the sense that Docker is the reason Go keeps being developed), and many users, and constant updating (and probably a lot of tooling and automation). I don't see much from the Node world to consider installing globally (meaning managed by Portage) and using everyday outside of a Node-based (or Yarn-based) project. I also don't consider it too much of a burden to add ~/.node/bin to PATH. I am on a single user PC, but those with a server shared between users may want to have a truly global Node setup without using npm -g alongside Portage. This hypothetical user base is probably way too small to support right now. The convenience is high (one package manager to rule them all) but the cost is much higher. One could argue for something like 'create-react-app' having an ebuild, but if all its dependencies also had ebuilds, it would be the one of the largest dep trees if not the largest, just for one package. Nightmarish to maintain because the next update will probably update a significant number of those deps too. Things like ESLint and Webpack would be a nightmare too, especially once their plugins get involved. Again the question here is whether Portage would even scale well with this many packages brought in from Node, treated the way we treat Python packages or Perl modules. Java is in a similar boat to something like Node. Anything that we want written in Java on Gentoo generally just gets added as a -bin ebuild. Even if this wasn't the case, it would be easier to maintain all-in-one ebuilds that grab all deps and build with Maven (which too is a bin only in Portage) as opposed to the separate deps. -- Andrew
