| 1 |
On Sun, 20 Oct 2019 20:05:40 -0400 |
| 2 |
Joshua Kinard <kumba@g.o> wrote: |
| 3 |
|
| 4 |
> Longer-term, I think this entire approach should be revisited by the TeX |
| 5 |
> team to make it behave more like Perl or Python packages by having discrete |
| 6 |
> ebuilds for these modules. That's not exactly a small undertaking, but |
| 7 |
> this current approach feels very kludgy in its design and is probably |
| 8 |
> asking for trouble. I looked at several of the modules on CTAN, and they |
| 9 |
> each have their own version and even have different licenses. |
| 10 |
|
| 11 |
With the current state of the portage dependency resolver, and with |
| 12 |
regards to the constant problems end users face with it, I really can't |
| 13 |
advise this unless you need to. |
| 14 |
|
| 15 |
Currently working on vendoring rust in an overlay, and 128 ebuilds just |
| 16 |
to satisfy the dependencies enough to test *one* package is a bit of a |
| 17 |
piss-take. |
| 18 |
|
| 19 |
I'd suggest waiting a few years for portage to see some improvements |
| 20 |
here before taking on something that ambitious when the current |
| 21 |
approach works well enough. |
Archives