| 1 |
On 2020-10-05 20:30, Azamat Hackimov wrote: |
| 2 |
|
| 3 |
> Is there a slotmove that can be applied? |
| 4 |
|
| 5 |
I am afraid I do not understand the question. What do you want to move, |
| 6 |
and why? |
| 7 |
|
| 8 |
> Can be lua:0 and lua:5.1 coexist? |
| 9 |
|
| 10 |
In theory they can (I say "in theory" because app-eselect/eselect-lua |
| 11 |
ebuild currently block dev-lang/lua:0), except having :0 installed would |
| 12 |
conflict with using eselect-lua - which I guess might be acceptable |
| 13 |
during the transition period. Anyway, there are no file collisions |
| 14 |
between :0 and :5.1, and while the two use the same CMOD and LMOD |
| 15 |
directories (for the record, so does LuaJIT for now) this should be |
| 16 |
harmless - files in LMOD would be very much identical, and from what I |
| 17 |
recall from discussions on IRC compiled modules in CMOD must not link |
| 18 |
against Lua libraries themselves so they should be |
| 19 |
implementation-independent. |
| 20 |
|
| 21 |
> I think a better idea is to migrate the base set of lua packages |
| 22 |
|
| 23 |
Define "base set of lua packages". |
| 24 |
|
| 25 |
> (maybe under package.mask) |
| 26 |
|
| 27 |
...meaning that at some point in the future we would have to unmask |
| 28 |
slotted Lua AND all the ebuilds depending on it, potentially unleashing |
| 29 |
a torrent of errors. Although we cannot really avoid this step |
| 30 |
altogether, I would rather let maintainers adapt their Lua ebuilds to |
| 31 |
the eclasses first and handle slotted Lua as a separate step. |
| 32 |
|
| 33 |
-- |
| 34 |
MS |
Archives