| 1 |
> On 2021-01-31, at 18:17, Aisha Tammy <gentoo.user@×××××.cc> wrote: |
| 2 |
> |
| 3 |
> On 1/31/21 8:49 AM, Alessandro Barbieri wrote: |
| 4 |
>> I'm trying to package nodejs software and I made an overlay for it here |
| 5 |
>> https://github.com/Alessandro-Barbieri/node-overlay <https://github.com/Alessandro-Barbieri/node-overlay> |
| 6 |
>> Could you try it and send feedback? |
| 7 |
> |
| 8 |
> |
| 9 |
> I have to confess, I don't like nodejs a lot. |
| 10 |
> But don't node packages have a very strict version dependency? |
| 11 |
> Does this handle version conflicts? |
| 12 |
> |
| 13 |
> X needs >=A-1.2 and <=A-1.3 |
| 14 |
> Y needs >=A-1.5 |
| 15 |
> |
| 16 |
> How would this be solved here? Isn't it for this reason that |
| 17 |
> package installs are to a local folder for each application? |
| 18 |
|
| 19 |
It can't be done in a sane way. Nodejs, because of their unwillingness to solve dependency issues and allowing insane amounts of tiny packages to exist (blame the community), allow insane dependency trees that make it impossible to put it on top of a normal package manager. |
| 20 |
|
| 21 |
Even if we did find packages that don't have these conflicts, having Portage manage thousands of packages just for a single thing like eslint seems like a very bad idea. |
| 22 |
|
| 23 |
Our best option is to treat Nodejs stuff the way we treat Rust and Go packages. Pretend Nodejs 'binaries' are 'built' statically and therefore, grab all the dependencies in the main package ebuild. One example is this overlay's vscode ebuild: https://data.gpo.zugaina.org/pf4public/app-editors/vscode/vscode-1.52.1.ebuild |
| 24 |
|
| 25 |
The process of generating the SRC_URI can be automated. Eclasses could be written for to help with the phases, especially src_unpack and src_prepare. |
Archives