Re: [gentoo-user] Nodejs overlay
On Mon, 2021-02-01 at 05:23 -0500, Andrew Udvare wrote: > > > > 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. > 10 is small, but 10 factorial is not. With node, every dependency of every dependency of every dependency of every dependency... is bundled and installed. No matter how small each individual package is, the big- O is what kills you. It really shouldn't take 114MiB of code in 15,092 files and 1,875 directories to display a bullet list: https://dev.to/leoat12/the-nodemodules-problem-29dc > 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. I wasn't really thinking about the distfiles, because you can delete them after. Everything you build in Rust and Go gets linked into an executable and takes up space in the executable, which is installed and has to stay there. > > 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. The same big-O problem. If you actually update a bundled package when its dependencies are updated, you'll be updating every ebuild multiple times a day. > > 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. You think it does, which is precisely the problem. The big-O issue makes it completely infeasible to do security updates for Go packages. If someone tells you they are, they're lying. What they mean is "if someone reports a problem, we fix it," which just punts to it being mathematically "impossible" to find and report the problems. People might look for problems in docker itself, or in the latest version of some library it uses, but nobody is looking for security issues in the specific version of library A used by the specific version of library B used by the specific version of library C used by the specific version of library D used by docker. > > 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. Go has dynamic linking since forever. Obviously I agree that having everything managed by portage is nice, but the benefits that you get out of having a rationally-developed C library installed with portage and the latest Go doohickey installed with portage are wildly different. The Go stuff takes a lot more work, and you get a lot less out of it -- to the extent that maybe it's not worth all the trouble (and we shouldn't be installing vulnerable stuff on everyone's machines).
Re: [gentoo-user] Nodejs overlay
> On 2021-01-31, at 19:20, Michael Orlitzky 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
Re: [gentoo-user] Nodejs overlay
Il Lun 1 Feb 2021, 00:20 Aisha Tammy ha scritto: > On 1/31/21 8:49 AM, Alessandro Barbieri wrote: > > I'm trying to package nodejs software and I made an overlay for it here > > https://github.com/Alessandro-Barbieri/node-overlay < > https://github.com/Alessandro-Barbieri/node-overlay> > > Could you try it and send feedback? > > > I have to confess, I don't like nodejs a lot. > But don't node packages have a very strict version dependency? > Does this handle version conflicts? > > X needs >=A-1.2 and <=A-1.3 > Y needs >=A-1.5 > > How would this be solved here? Isn't it for this reason that > package installs are to a local folder for each application? > > I don't know if going to global installs is the best idea. > But I'm willing to be enlightened and proven wrong :) > > Best, > Aisha > This will sound crazy but I'm completely ignoring version requirements (even for major versions because I don't know how to slot without becoming mad). Some packages will require patching to work. I'll see how it goes this way, I have nothing to lose, at least I have tried >
RE: [gentoo-user] news 2021-01-30-display-manager-init -- blocked package
ST Restricted > -Original Message- > From: Kusoneko > Sent: Sunday, January 31, 2021 05:02 > To: gentoo-user@lists.gentoo.org > Cc: Kusoneko > Subject: [gentoo-user] news 2021-01-30-display-manager-init -- blocked > package > > > Following my daily syncing today, 2 news items appeared, the important > one for this being the following: > > 2021-01-30-display-manager-init > > It states that starting the next xorg-server version, the xdm init > script will be removed and that one install gui-libs/display-manager-init to > replace it. > Following the instructions to install said package leads to a > wonderful error stating that the package is blocked by the following packages: > > x11-apps/xinit-1.4.1 > sys-apps/sysvinit-2.98 > x11-base/xorg-server-1.20.10 > > Removing xorg-server is not gonna happen, so looking at what emerge > says, there's a bit of an issue here: > > https://zifb.in/GUtgto4VcX > > Doing the required update is currently impossible. > > I am definitely not gonna remember about this in a week or 2 so I'd > like to deal with whatever this issue is asap. Is there any way to do this? > > Note: all 3 of the blocking packages and whatever pulls them in are > NOT using the ~amd64 keyword at the moment, except for nvidia-drivers. > > Thanks for any help, > Kusoneko. You already solved, so this is just for other's info: in my case (unstable amd64) I saw the news item, tried to emerge display-manager-init, got your same block, let the emerge run to completion and _then_ succeeded emerging display-manager-init, which is now running happily at startup. raffaele
