[devel] I: texlive 2016 is going to come

[devel] I: texlive 2016 is going to come

[Igor Vlasenko]

Уважаемые господа,

после обновления perl до 5.26
буду готовить обновление texlive в Сизифе.

За основу будет взята сборка texlive в Fedora или в Mageia.

Пожелания, замечания приветствуются.

-- 

I V

Re: [devel] I: texlive 2016 is going to come

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Thu, Dec 14, 2017 at 09:44:17PM +0200, Igor Vlasenko wrote:
> Уважаемые господа,
> 
> после обновления perl до 5.26
> буду готовить обновление texlive в Сизифе.
> 
> За основу будет взята сборка texlive в Fedora или в Mageia.

Больше нигде texlive не пакуют?

Не делайте так, как в Федоре, пожалуйста - это ужас-ужас.
Расскажите, пожалуйста, как это сделано в Магейе.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: texlive 2016 is going to come

[Igor Vlasenko]

On Thu, Dec 14, 2017 at 11:59:01PM +0300, Dmitry V. Levin wrote:
> On Thu, Dec 14, 2017 at 09:44:17PM +0200, Igor Vlasenko wrote:
> > Уважаемые господа,
> > 
> > после обновления perl до 5.26
> > буду готовить обновление texlive в Сизифе.
> > 
> > За основу будет взята сборка texlive в Fedora или в Mageia.
> 
> Больше нигде texlive не пакуют?
> 
> Не делайте так, как в Федоре, пожалуйста - это ужас-ужас.

ужас-ужас это у нас, 8 лет не обновлялось.

Там просто, как я понимаю, ужас. 
Хуже, чем уже есть, не будет.
Но хотелось бы конкретнее.

> Расскажите, пожалуйста, как это сделано в Магейе.

Лучше один раз увидеть, чем 100 раз услышать ;)
Готовые пакеты есть, их можно посмотреть в соотв.
репозиториях (Федора и Mageia).

мой предыдущий подход 2 года назад можно посмотреть на
http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/


-- 

I V

Re: [devel] I: texlive 2016 is going to come

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

On Thu, Dec 14, 2017 at 11:26:23PM +0200, Igor Vlasenko wrote:
> On Thu, Dec 14, 2017 at 11:59:01PM +0300, Dmitry V. Levin wrote:
> > On Thu, Dec 14, 2017 at 09:44:17PM +0200, Igor Vlasenko wrote:
> > > Уважаемые господа,
> > > 
> > > после обновления perl до 5.26
> > > буду готовить обновление texlive в Сизифе.
> > > 
> > > За основу будет взята сборка texlive в Fedora или в Mageia.
> > 
> > Больше нигде texlive не пакуют?
> > 
> > Не делайте так, как в Федоре, пожалуйста - это ужас-ужас.
> 
> ужас-ужас это у нас, 8 лет не обновлялось.
> 
> Там просто, как я понимаю, ужас. 
> Хуже, чем уже есть, не будет.
> Но хотелось бы конкретнее.

Конкретнее:

$ grep -c ^Source fedora/texlive.spec
7318
$ grep -c ^%package fedora/texlive.spec
5930

Помимо того, что это неразумно, такой пакет у нас просто не соберётся
по времени.

Наша задача в скором будущем обеспечить собираемость *каждого* пакета
за 2 часа.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: texlive 2016 is going to come

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

On Fri, 15 Dec 2017 00:36:38 +0300 Dmitry V. Levin wrote:
[...]
> Конкретнее:
> 
> $ grep -c ^Source fedora/texlive.spec
> 7318
> $ grep -c ^%package fedora/texlive.spec
> 5930
> 
> Помимо того, что это неразумно, такой пакет у нас просто не соберётся
> по времени.
> 
> Наша задача в скором будущем обеспечить собираемость *каждого* пакета
> за 2 часа.

Чего ради столь жесткое ограничение? В зависимости от железа, тот
же guile22, libreoffice или chromium в 2 часа не соберётся,
особенно в один поток. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] I: texlive 2016 is going to come

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]

On Fri, Dec 15, 2017 at 02:17:59AM +0300, Andrey Savchenko wrote:
> On Fri, 15 Dec 2017 00:36:38 +0300 Dmitry V. Levin wrote:
> [...]
> > Конкретнее:
> > 
> > $ grep -c ^Source fedora/texlive.spec
> > 7318
> > $ grep -c ^%package fedora/texlive.spec
> > 5930
> > 
> > Помимо того, что это неразумно, такой пакет у нас просто не соберётся
> > по времени.
> > 
> > Наша задача в скором будущем обеспечить собираемость *каждого* пакета
> > за 2 часа.
> 
> Чего ради столь жесткое ограничение? В зависимости от железа, тот
> же guile22, libreoffice или chromium в 2 часа не соберётся,
> особенно в один поток. 

Допустим, что мы исправили собираемость всех пакетов в Сизифе.  Тогда,
если у нас есть достаточно производительное железо и нет ограничения
сборки в один поток, то мы можем выявлять потенциальные сборочные
регрессии в репозитории при сборке новых пакетов достаточно быстро
(скажем, до 2 часов), чтобы позволить себе включить пересборочный
тест для каждого задания (привет at@).

Есть и другие мысли, которые можно было бы реализовать, если бы сборка
самого долго собирающегося пакета укладывалась бы в относительно небольшой
временной интервал.

Разумеется, всё это касается только тех архитектур, для которых может быть
достаточно производительное железо (x86_64, aarch64).
На остальных архитектурах придётся довольствоваться тем, что есть.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: texlive 2016 is going to come

[Denis Medvedev]

On пятница, 15 декабря 2017 г. 2:38:00 MSK Dmitry V. Levin wrote:
> On Fri, Dec 15, 2017 at 02:17:59AM +0300, Andrey Savchenko wrote:
> > On Fri, 15 Dec 2017 00:36:38 +0300 Dmitry V. Levin wrote:
> > [...]
> > 
> > > Конкретнее:
> > > 
> > > $ grep -c ^Source fedora/texlive.spec
> > > 7318
> > > $ grep -c ^%package fedora/texlive.spec
> > > 5930
> > > 
> > > Помимо того, что это неразумно, такой пакет у нас просто не соберётся
> > > по времени.
> > > 
> > > Наша задача в скором будущем обеспечить собираемость *каждого* пакета
> > > за 2 часа.
> > 
> > Чего ради столь жесткое ограничение? В зависимости от железа, тот
> > же guile22, libreoffice или chromium в 2 часа не соберётся,
> > особенно в один поток.
> 
> Допустим, что мы исправили собираемость всех пакетов в Сизифе.  Тогда,
> если у нас есть достаточно производительное железо и нет ограничения
> сборки в один поток, то мы можем выявлять потенциальные сборочные
> регрессии в репозитории при сборке новых пакетов достаточно быстро
> (скажем, до 2 часов), чтобы позволить себе включить пересборочный
> тест для каждого задания (привет at@).
> 
> Есть и другие мысли, которые можно было бы реализовать, если бы сборка
> самого долго собирающегося пакета укладывалась бы в относительно небольшой
> временной интервал.
> 
> Разумеется, всё это касается только тех архитектур, для которых может быть
> достаточно производительное железо (x86_64, aarch64).
> На остальных архитектурах придётся довольствоваться тем, что есть.

Я правильно понимаю, что ограничение в один поток на сборочнице будет снято?!

Re: [devel] I: texlive 2016 is going to come

[Anton Farygin]

15.12.2017 07:23, Denis Medvedev пишет:
>> Разумеется, всё это касается только тех архитектур, для которых может быть
>> достаточно производительное железо (x86_64, aarch64).
>> На остальных архитектурах придётся довольствоваться тем, что есть.
> Я правильно понимаю, что ограничение в один поток на сборочнице будет снято?!

Речь идёт про пересборку репозитория за два часа, а не сборку одного 
пакета за два часа.

Re: [devel] I: texlive 2016 is going to come

[Igor Vlasenko]

On Fri, Dec 15, 2017 at 02:38:00AM +0300, Dmitry V. Levin wrote:
> > > Наша задача в скором будущем обеспечить собираемость *каждого* пакета
> > > за 2 часа.

Задача вполне разумная, если поддерживать списки исключений.

Без них же вспоминается анекдот.

- Хочу предложить вашему предприятию последнее своё изобретение. Это автомат для бритья. Клиент опускает монеты, просовывает голову в отверстие, и две бритвы начинают его гладко брить. boro.da33.ru
- Но ведь у каждого человека индивидуальное строение лица.
- В первый раз да!

Еще вспоминается Прокрустово ложе со схожим идеологическим обоснованием.
С гибким списком исключений можно обеспечить релевантную пересборку и за 1 час.

А пакеты, которые не вписываются в ограничение 2 часа, есть.

Сначала cross-gcc не влезал в тайминги,
приходилось его кастрировать, выбрасывая 2 десятка архитектур.

Потом новый libint стал собираться 8 часов, при чем там уже ничего не отрежешь.
повесил
https://bugzilla.altlinux.org/show_bug.cgi?id=31683
"big packages: an option to adjust hasher-priv time elapsed limit in task run"
Решения, как собрать такой пакет в Сизиф, нет.
Плюнул, собрал в autoimports :(

Но не у всех есть свой autoimports.

-- 

I V

Re: [devel] I: texlive 2016 is going to come

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Fri, Dec 15, 2017 at 01:32:55PM +0200, Igor Vlasenko wrote:
> On Fri, Dec 15, 2017 at 02:38:00AM +0300, Dmitry V. Levin wrote:
> > > > Наша задача в скором будущем обеспечить собираемость *каждого* пакета
> > > > за 2 часа.
> 
> Задача вполне разумная, если поддерживать списки исключений.
> 
> Без них же вспоминается анекдот.
> 
> - Хочу предложить вашему предприятию последнее своё изобретение. Это автомат для бритья. Клиент опускает монеты, просовывает голову в отверстие, и две бритвы начинают его гладко брить. boro.da33.ru
> - Но ведь у каждого человека индивидуальное строение лица.
> - В первый раз да!
> 
> Еще вспоминается Прокрустово ложе со схожим идеологическим обоснованием.
> С гибким списком исключений можно обеспечить релевантную пересборку и за 1 час.
> 
> А пакеты, которые не вписываются в ограничение 2 часа, есть.
> 
> Сначала cross-gcc не влезал в тайминги,
> приходилось его кастрировать, выбрасывая 2 десятка архитектур.

Этот пакет паталогически устроен: неправильно собирать один и тот же код
последовательно под зиллион архитектур.  Надеюсь, glebfm@ исправит.

> Потом новый libint стал собираться 8 часов, при чем там уже ничего не отрежешь.

Значит, можно распараллелить.

Если пакет собирается вечность и сборка не распараллеливается тем
или иным способом, значит, кто-то этот пакет неправильно собирает.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[devel] не все пакеты одинаково собираются (was: I: texlive 2016 is going to come)

[Michael Shigorin]

On Fri, Dec 15, 2017 at 02:41:13PM +0300, Dmitry V. Levin wrote:
> > Потом новый libint стал собираться 8 часов,
> > причем там уже ничего не отрежешь.
> Значит, можно распараллелить.

...с nprocs=1, ага (речь же явно шла про git.alt).

Дим, тут действительно напрашивается минимум два варианта --
причём под обмолот "лёгких" и "тяжёлых" пакетов есть прямой
смысл вообще по-разному выбирать железо для сборочниц.

Лично меня вполне бы устроил для начала флажок "тяжёлый пакет",
выставляемый на git.alt административно и отправляющий пакет при
сборке на "тяжёлый" узел.  Заодно это позволило бы поднять
степень параллелизма при сборке "лёгких" пакетов даже на
имеющемся прямо сейчас оборудовании -- например, можно один
из узлов выделить в "тяжёлый", три остальных определить
"лёгкими".  Возможно, для "тяжёлых" разрешать и параллельную
сборку, хотя тогда ожидаемы поползновения насчёт границы.

А в дальнейшем можно поставить один быстрый (и дорогой) сервер
на обмолот в первую очередь "тяжёлых" заданий, остальные же
разгребать оптимальными по цене процессорами как при текущей
сборке в репозитории, так и при пересборках разного толка.

И в ещё более дальнейшем автоматизировать "развесовку" с учётом
реально потребляемых при сборке ресурсов, желательно с историей.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] не все пакеты одинаково собираются

[Denis Medvedev]

On 12/18/2017 11:52 AM, Michael Shigorin wrote:
> On Fri, Dec 15, 2017 at 02:41:13PM +0300, Dmitry V. Levin wrote:
>>> Потом новый libint стал собираться 8 часов,
>>> причем там уже ничего не отрежешь.
>> Значит, можно распараллелить.
> ...с nprocs=1, ага (речь же явно шла про git.alt).
>
> Дим, тут действительно напрашивается минимум два варианта --
> причём под обмолот "лёгких" и "тяжёлых" пакетов есть прямой
> смысл вообще по-разному выбирать железо для сборочниц.
>
> Лично меня вполне бы устроил для начала флажок "тяжёлый пакет",
> выставляемый на git.alt административно и отправляющий пакет при
> сборке на "тяжёлый" узел.  Заодно это позволило бы поднять
> степень параллелизма при сборке "лёгких" пакетов даже на
> имеющемся прямо сейчас оборудовании -- например, можно один
> из узлов выделить в "тяжёлый", три остальных определить
> "лёгкими".  Возможно, для "тяжёлых" разрешать и параллельную
> сборку, хотя тогда ожидаемы поползновения насчёт границы.
> сторией.
>
Тяжелые узлы - за, возможность параллельной сборки в тестовом режиме - 
тоже за.
А вот коммитить я бы разрешал только задания, собранные без параллельной 
сборки.
То есть отладился c test-only, parallel=yes, запустил test-only, 
parallel=no и закоммитил в репозиторий.

Re: [devel] не все пакеты одинаково собираются

[Aleksei Nikiforov]

Здравствуйте.

18.12.2017 13:36, Denis Medvedev пишет:
> On 12/18/2017 11:52 AM, Michael Shigorin wrote:
> Тяжелые узлы - за, возможность параллельной сборки в тестовом режиме - 
> тоже за.
> А вот коммитить я бы разрешал только задания, собранные без параллельной 
> сборки.
> То есть отладился c test-only, parallel=yes, запустил test-only, 
> parallel=no и закоммитил в репозиторий.
У меня есть вопрос: почему коммиттить только без параллельной сборки? 
Чем обосновано такое ограничение? Есть ли причины кроме "исторически так 
сложилось"?

С уважением,
Алексей Никифоров

Re: [devel] не все пакеты одинаково собираются

[Denis Medvedev]

On 12/18/2017 02:00 PM, Aleksei Nikiforov wrote:
> Здравствуйте.
>
> 18.12.2017 13:36, Denis Medvedev пишет:
>> On 12/18/2017 11:52 AM, Michael Shigorin wrote:
>> Тяжелые узлы - за, возможность параллельной сборки в тестовом режиме 
>> - тоже за.
>> А вот коммитить я бы разрешал только задания, собранные без 
>> параллельной сборки.
>> То есть отладился c test-only, parallel=yes, запустил test-only, 
>> parallel=no и закоммитил в репозиторий.
> У меня есть вопрос: почему коммиттить только без параллельной сборки? 
> Чем обосновано такое ограничение? Есть ли причины кроме "исторически 
> так сложилось"?
Cостояние гонки при сборке дистрибутива приводит к крайне интересным 
эффектам при попытке пересобрать такой пакет повторно...

Re: [devel] не все пакеты одинаково собираются

[Sergey Bolshakov]

>>>>> "Denis" == Denis Medvedev <nbr-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On 12/18/2017 02:00 PM, Aleksei Nikiforov wrote:
 >> Здравствуйте.
 >> 
 >> 18.12.2017 13:36, Denis Medvedev пишет:
 >>> On 12/18/2017 11:52 AM, Michael Shigorin wrote:
 >>> Тяжелые узлы - за, возможность параллельной сборки в тестовом
 >>> режиме - тоже за.
 >>> А вот коммитить я бы разрешал только задания, собранные без
 >>> параллельной сборки.
 >>> То есть отладился c test-only, parallel=yes, запустил test-only,
 >>> parallel=no и закоммитил в репозиторий.
 >> У меня есть вопрос: почему коммиттить только без параллельной
 >> сборки? Чем обосновано такое ограничение? Есть ли причины кроме
 >> "исторически так сложилось"?
 > Cостояние гонки при сборке дистрибутива приводит к крайне интересным
 > эффектам при попытке пересобрать такой пакет повторно...

По очевидным причинам сборка на arm уже несколько лет происходит
в несколько (сейчас 8) потоков, каких-либо разломов по этой причине
не припомню.

-- 

Re: [devel] не все пакеты одинаково собираются

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

On Mon, Dec 18, 2017 at 11:52:47AM +0300, Michael Shigorin wrote:
> On Fri, Dec 15, 2017 at 02:41:13PM +0300, Dmitry V. Levin wrote:
> > > Потом новый libint стал собираться 8 часов,
> > > причем там уже ничего не отрежешь.
> > Значит, можно распараллелить.
> 
> ...с nprocs=1, ага (речь же явно шла про git.alt).

Ну давайте уберём nprocs=1, если мешает.

> Дим, тут действительно напрашивается минимум два варианта --
> причём под обмолот "лёгких" и "тяжёлых" пакетов есть прямой
> смысл вообще по-разному выбирать железо для сборочниц.

Почему?  Это *совершенно* не очевидно.
Поделись, если ты делал какие-то замеры на эту тему.

> Лично меня вполне бы устроил для начала флажок "тяжёлый пакет",
> выставляемый на git.alt административно и отправляющий пакет при
> сборке на "тяжёлый" узел.  Заодно это позволило бы поднять
> степень параллелизма при сборке "лёгких" пакетов даже на
> имеющемся прямо сейчас оборудовании -- например, можно один
> из узлов выделить в "тяжёлый", три остальных определить
> "лёгкими".  Возможно, для "тяжёлых" разрешать и параллельную
> сборку, хотя тогда ожидаемы поползновения насчёт границы.

Такие костыли никто не захочет реализовывать, насколько я понимаю.

> А в дальнейшем можно поставить один быстрый (и дорогой) сервер
> на обмолот в первую очередь "тяжёлых" заданий, остальные же
> разгребать оптимальными по цене процессорами как при текущей
> сборке в репозитории, так и при пересборках разного толка.

Да не нужен никакой быстрый и дорогой сервер, если даже самый тяжёлый
пакет, который есть в Сизифе (chromium), на совершенно бюджетных
2 * E5-2620v4 сейчас собирается с -j16 примерно за час.

> И в ещё более дальнейшем автоматизировать "развесовку" с учётом
> реально потребляемых при сборке ресурсов, желательно с историей.

Это подразумевается сразу, а не в дальнейшем.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] I: texlive 2016 is going to come

[Igor Vlasenko]

On Fri, Dec 15, 2017 at 12:36:38AM +0300, Dmitry V. Levin wrote:
> Конкретнее:
> 
> $ grep -c ^Source fedora/texlive.spec
> 7318
> $ grep -c ^%package fedora/texlive.spec
> 5930
> 
> Помимо того, что это неразумно, такой пакет у нас просто не соберётся
> по времени.

А. В этом вопрос. Тогда можно не опасаться.
Пакет собирается достаточно быстро 
(как я помню, 2 года назад было менее 30 мин).

С этими 7318/5930 происходит распаковка и копирование,
очень быстрый процесс. А вот если бы я вдруг нагенерировал бы
7318/5930 малых пакетов, то время сборки увеличилось бы
на 7318/5930 * (create chroot+instal deps).
Тогда их за 2 часа и в 32 потока не собрать.


-- 

I V

Re: [devel] I: texlive 2016 is going to come

[Kirill Maslinsky]

Igor Vlasenko writes:

> On Thu, Dec 14, 2017 at 11:59:01PM +0300, Dmitry V. Levin wrote:
>> On Thu, Dec 14, 2017 at 09:44:17PM +0200, Igor Vlasenko wrote:
>> > после обновления perl до 5.26
>> > буду готовить обновление texlive в Сизифе.

Здорово! Спасибо, Игорь.

>> > За основу будет взята сборка texlive в Fedora или в Mageia.

[...]

>> Не делайте так, как в Федоре, пожалуйста - это ужас-ужас.
>
> ужас-ужас это у нас, 8 лет не обновлялось.

Это верно. Но, кстати, проблема с обновлением была вызвана отчасти тем,
что 8 лет назад я принял неудачное решение паковать texlive, основываясь
на пакетах из Дебиана. Была идея оседлать ветер^Wэкспертизу дебиана, и
на этом сэкономить. Практика показала, что для интеграции пришлось
написать немало нетривиального кода, нагородить очень сложную структуру
репозитория, предполагающую многоступенчатый мердж, в которой никто
не мог и не хотел разбираться через полгода, включая меня. А задачи и
инфраструктура у нас были все равно настолько другие, что гораздо больше
в пакетах в итоге было заново переделано, чем заимствовано из дебиана.
Коротко говоря, идея «сделать как у других» не оправдалась.

> Там просто, как я понимаю, ужас.
> Хуже, чем уже есть, не будет.
> Но хотелось бы конкретнее.

Мне кажется, в современной ситуации засилья внешних пакетных менеджеров
у каждой на что-то претендующей подсистемы, целесообразной схемой будет:

1. Упаковка бинарных программ texlive (из дерева Build/source) в один или
несколько пакетов (более-менее как было, texlive-base-bin и т.п.)

2. Упаковка минимальной доли данных (texmf-dist), необходимых для работы
базовых программ (форматы, переносы, что-то еще), чтобы получился пакет,
напрмиер, latex-base, которым можно было бы скомпилировать латеховский
документ, не использующий внешних пакетов или использующий какое-то
минимальное подмножество. Эта задача не совсем тривиальная (потому что
апстим ее вовсе себе не ставит, не знаю — ставят ли другие
дистрибутивы), но вполне разрешимая. Обеспечить тем самым востребованное
для сборки подмножество латеха для сборочной среды.

3. Упаковка апстримного tlmgr для того, чтобы пользователи могли с его
помощью устанавливать и обновлять себе отдельные латеховские пакеты
(теперь же уже каждый сам себе пакетный менеджер, почему бы и техливу не
разрешить). Может быть, с каким-то патчем, чтобы ядро (texlive-base-bin)
tlmgr не трогал, только все остальное.

4. Обеспечить упаковку отдельных латеховских модулей в виде пакетов в
Сизифе, примерно (или точно) по нашему старому ТеХ-полиси:
https://www.altlinux.org/TeX_Policy

Вообще полиси можно перечитать свежим взглядом и сформулировать, что в
нем устарело, и почему.

> мой предыдущий подход 2 года назад можно посмотреть на
> http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/

А что тогда помешало закончить, если это что-то техническое?

--
КМ

Re: [devel] I: texlive 2016 is going to come

[Igor Vlasenko]

On Fri, Dec 15, 2017 at 10:05:31PM +0100, Kirill Maslinsky wrote:

Спасибо большое!

> > мой предыдущий подход 2 года назад можно посмотреть на
> > http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/
> А что тогда помешало закончить, если это что-то техническое?

Была одна техническая причина, не уверен был, насколько хорошо
были прописаны конфликты и Obsoletes для беспроблемного обновления
(в настоящее время достаточно тривиально решается с помощью distromap)
и вторая, был сильно загружен, и не хотел брать ответственность
за такой важный пакет.

Обе причины сейчас не так актуальны.
 
> Мне кажется, в современной ситуации засилья внешних пакетных менеджеров
> у каждой на что-то претендующей подсистемы, целесообразной схемой будет:
> 
> 1. Упаковка бинарных программ texlive (из дерева Build/source) в один или
> несколько пакетов (более-менее как было, texlive-base-bin и т.п.)
> 
> 2. Упаковка минимальной доли данных (texmf-dist), необходимых для работы
> базовых программ (форматы, переносы, что-то еще), чтобы получился пакет,
> напрмиер, latex-base, которым можно было бы скомпилировать латеховский
> документ, не использующий внешних пакетов или использующий какое-то
> минимальное подмножество. Эта задача не совсем тривиальная (потому что
> апстим ее вовсе себе не ставит, не знаю — ставят ли другие
> дистрибутивы), но вполне разрешимая. Обеспечить тем самым востребованное
> для сборки подмножество латеха для сборочной среды.
> 
> 3. Упаковка апстримного tlmgr для того, чтобы пользователи могли с его
> помощью устанавливать и обновлять себе отдельные латеховские пакеты
> (теперь же уже каждый сам себе пакетный менеджер, почему бы и техливу не
> разрешить). Может быть, с каким-то патчем, чтобы ядро (texlive-base-bin)
> tlmgr не трогал, только все остальное.
> 
> 4. Обеспечить упаковку отдельных латеховских модулей в виде пакетов в
> Сизифе, примерно (или точно) по нашему старому ТеХ-полиси:
> https://www.altlinux.org/TeX_Policy
> 
> Вообще полиси можно перечитать свежим взглядом и сформулировать, что в
> нем устарело, и почему.

Хочу 4) сохранить в любом случае.
3) - tlmgr -- я переносил прошлый раз код с нашего texlive,
попытаюсь и в этот раз.

По поводу 1)-2) есть некоторые детали,
попробую написать в отдельном письме.

-- 

I V