| 1 |
Hi Alexis, |
| 2 |
|
| 3 |
> The real reason is that we need to go through ~arch testing, fixing rev |
| 4 |
> deps that might need update to their .tex files because the underlying |
| 5 |
> packages they use has changed, adapt the deps for some potential |
| 6 |
> changes, and then a stablereq round. |
| 7 |
|
| 8 |
I agree. This makes the situation not easier. |
| 9 |
|
| 10 |
> [...] |
| 11 |
>> This is not a very nice solution, but it works so far. One difficulty |
| 12 |
>> is, that there is no 1:1 relation between the texlive distribution and |
| 13 |
>> dev-texlive/* at the moment. |
| 14 |
> There is a 1:1 relation. |
| 15 |
|
| 16 |
A full installation of TeXLive installs packages, which are in |
| 17 |
dev-tex/* and dev-texlive/* on gentoo. |
| 18 |
On the other hand single packages are bundled some times. |
| 19 |
Some programs/packages can be found in dev-tex/* and dev-texlive/* |
| 20 |
|
| 21 |
I remember, that I last we had for example dev-tex/notoccite in the tree |
| 22 |
and dev-texlive/texlive-latexextra including shipped the same, but newer |
| 23 |
files. |
| 24 |
This is what I meant with "no 1:1 relation" |
| 25 |
|
| 26 |
>> How can we enable our users to run a recent TeXLive in a clean way? |
| 27 |
> /usr/local/share/texmf has been supported by texlive on Gentoo from day |
| 28 |
> one. You can use that. It's an overlay that takes precedence on |
| 29 |
> anything else, so per the above, you lose all the QA & testing done |
| 30 |
> behind the scenes if you use this. |
| 31 |
|
| 32 |
And packages which depend on a specific LaTeX package will not install. |
| 33 |
So the user has to provide a package.provided list, which is not so nice |
| 34 |
to maintain for so many packages. |
| 35 |
|
| 36 |
-- |
| 37 |
Best, |
| 38 |
Jonas |
Archives