[sisyphus] RoboTeX newsletter III.

[sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

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

В репозиторий-карман autoextra:texlive/Sisyphus
http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/ 
выложена текущая сборка импортированного texlive-2014,
сборка под Sisyphus/x86_64 и под Sisyphus/i586.

Сборка предназначена для тестирования.
Конечно, желательно было бы собрать и под p7,
но там надо будет портировать из Сизифа патченый rpm-build -
наши инструменты не расчитаны на сборку srpm,
у которого так много подпакетов (> 5000).

Имея под рукой патченый rpm-build и зная тайные настройки
hasher, у нас этот пакет можно собрать за 3-4 часа,
без них этот процесс растянется на много суток.

Этим релизом я хочу зафиксировать некий промежуточный результат,
а именно, что удалось, надеюсь, собрать 
рабочий устанавливающийся texlive-2014.

Следующий этап --- адаптировать texlive-2014 
и наше TeX полиси друг к другу и подготовить 
texlive-2014 к выкладыванию в Сизиф.

Эта задача облегчается тем, что texlive-2014 --
полная и одновременно свежая сборка, что позволяет
заменить ей все остальные пакеты texlive-*, tetex-*,
и texmf-* в Сизифе и начать новые полиси с чистого листа.

Что изменить в текущем полиси 
и что осталось изменить в texlive-2014.
--------------------------------------

1) хотел бы отказаться от автоматических provides вида 
texmf(latex/siunitx), поскольку каталоги в ТеХ не играют особой роли,

 $ kpsepath -w tex siunitx.sty           
/usr/share/texmf-texlive/tex/latex/siunitx/siunitx.sty
 $ kpsepath -w tex si-units.cfg          
/usr/share/texmf-texlive/tex/latex/siunitx/config/si-units.cfg

и есть прецеденты, когда файлы переезжают в подкаталог/надкаталог,
сбивая автоматические texmf(...).
Отсюда следует, что texmf(...) это не инварианты, от них надо
отказаться, чтобы не создавать проблем, возможно, в пользу файловых
provides tex(siunitx.sty), tex(si-units.cfg).

2) адаптировать нашу схему с /etc/texmf/
и полностью переехать c %post/un на filetriggers.

В федоре использовалась прямолинейная схема вида
%post aleph
[...]
sed -i 's/^\#\!\ aleph.*$/aleph aleph - *aleph.ini/' %{_texdir}/texmf-dist/web2c/fmtutil.cnf
sed -i 's/^\#\!\ lamed.*$/lamed aleph language.dat *lambda.ini/' %{_texdir}/texmf-dist/web2c/fmtutil.cnf

мне кажется, что наша схема с fmt.d/ updmap.d/ более надежная.
Но, c ней есть ряд вопросов.

есть мысль чтобы уменьшить число конфликтов при обновлении, 
и руководствуясь /etc полиси, что в /etc не место автогенерированным
файлам, не предназначенным для редактирования, и
пользуясь возможностью начать новые полиси с чистого листа.
можно вынести fmt.d/ updmap.d/ language.d/ для texlive-2014
в подкаталог в /usr/share/(?)

3) В текущем виде одного большого srpm texlive-2014 в Сизиф не
пропихивается. Как решить эту проблему?

У меня есть намерение написать собственный конвертер-генератор
tlpobj в srpm. Недостаток такого подхода в том, что в сизиф
добавится > 5000 новых srpm, а достоинство в том, что 
он позволяет continuous integration, т.е. texlive в Сизифе всегда
будет самый свежий и нужда в пересекающихся с texlive 
texmf-* пакетах просто отпадет.



-- 

I V

Re: [sisyphus] RoboTeX newsletter III.

[Bergman Andrey]

> У меня есть намерение написать собственный конвертер-генератор
> tlpobj в srpm. Недостаток такого подхода в том, что в сизиф
> добавится > 5000 новых srpm, а достоинство в том, что
> он позволяет continuous integration, т.е. texlive в Сизифе всегда
> будет самый свежий и нужда в пересекающихся с texlive
> texmf-* пакетах просто отпадет.

Это было бы здорово. Вообще, префикс texmf обозначает просто то, что источник пакета - это ни дистрибутив texlive, ни дистрибутив tetex. Т.е. если вы берёте пакеты непосредственно из CTAN (или bitbucket, как с pgf), то им желательно поставить префикс texmf.

Поэтому texmf лучше оставить - кто знает, может быть потом будет переезд на другой дистрибутив tex или texlive опять протухнет.

Андрей.

Андрей.

Re: [sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

On Fri, Nov 21, 2014 at 11:19:07PM +0300, Bergman Andrey wrote:
> > У меня есть намерение написать собственный конвертер-генератор
> > tlpobj в srpm. Недостаток такого подхода в том, что в сизиф
> > добавится > 5000 новых srpm, а достоинство в том, что
> > он позволяет continuous integration, т.е. texlive в Сизифе всегда
> > будет самый свежий и нужда в пересекающихся с texlive
> > texmf-* пакетах просто отпадет.
> 
> Это было бы здорово. Вообще, префикс texmf обозначает просто то, что источник пакета - это ни дистрибутив texlive, ни дистрибутив tetex. Т.е. если вы берёте пакеты непосредственно из CTAN (или bitbucket, как с pgf), то им желательно поставить префикс texmf.
> 
> Поэтому texmf лучше оставить - кто знает, может быть потом будет переезд на другой дистрибутив tex или texlive опять протухнет.


Я к сожалению не буду брать со CTAN, а из texlive development.
там есть свой аналог системы пакетов. к примеру:

 $ cat texlive.expanded/tlpkg/tlpobj/ledmac.tlpobj
name ledmac
category Package
revision 35264
shortdesc Typeset scholarly editions.
relocated 1
longdesc A macro package for typesetting scholarly critical editions.
longdesc The ledmac package is a LaTeX port of the plain TeX EDMAC
longdesc macros. It supports indexing by page and line number and simple
longdesc tabular- and array-style environments. The package is
longdesc distributed with the related ledpar and ledarab packages. The
longdesc package is now superseded by eledmac.
runfiles size=41
 RELOC/tex/latex/ledmac/afoot.sty
 RELOC/tex/latex/ledmac/ledarab.sty
 RELOC/tex/latex/ledmac/ledmac.sty
 RELOC/tex/latex/ledmac/ledpar.sty
catalogue-ctan /macros/latex/contrib/ledmac
catalogue-date 2014-09-26 05:36:34 +0200
catalogue-license lppl1.3
catalogue-version 0.19.2


-- 

I V

Re: [sisyphus] RoboTeX newsletter III.

[Bergman Andrey]

> Я к сожалению не буду брать со CTAN, а из texlive development.
> там есть свой аналог системы пакетов.

Тогда лучше сделать texlive пакеты с префиксом texlive. Или, может быть, добавить texliveNew какой-нибудь. Но возможность префикса texmf для пакетов-заплаток текущего дистрибутива TexLive просто необходимо оставить.

Опыт предыдущих лет показывает, что буквально через полгода либо появится пакет, не включённый в TeXLive, либо крайне устаревшей версии в TeXLive.

Разумеется, все устаревшие на данный момент texmf-пакеты нужно удалить, но нельзя отрекаться навсегда от этих заплаток.

Re: [sisyphus] RoboTeX newsletter III.

[Gleb Fotengauer-Malinovskiy]

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

On Fri, Nov 21, 2014 at 07:26:42PM +0200, Igor Vlasenko wrote:
> Уважаемые господа,
> 3) В текущем виде одного большого srpm texlive-2014 в Сизиф не
> пропихивается. Как решить эту проблему?
> 
> У меня есть намерение написать собственный конвертер-генератор
> tlpobj в srpm. Недостаток такого подхода в том, что в сизиф
> добавится > 5000 новых srpm, а достоинство в том, что 
> он позволяет continuous integration, т.е. texlive в Сизифе всегда
> будет самый свежий и нужда в пересекающихся с texlive 
> texmf-* пакетах просто отпадет.

Это повод сделать ещё один компонент наравне с classic и debuginfo и
делить texmf-* по принципу в classic -- тe texmf-*, которые есть в
зависимостях у пакетов из classic, а все остальные -- в отдельный
компонент.

-- 
glebfm

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

Re: [sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

On Sat, Nov 22, 2014 at 02:18:44AM +0300, Bergman Andrey wrote:
> Разумеется, все устаревшие на данный момент texmf-пакеты нужно удалить, но нельзя отрекаться навсегда от этих заплаток.

Конечно, согласен. Я имел в виду, что есть возможность
поменять текущее tex policy, поскольку какое-то время 
в сизифе не будет texmf-пакетов, так как все что есть - устаревшие.

-- 

I V

Re: [sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

On Sat, Nov 22, 2014 at 12:00:54PM +0400, Vladimir Didenko wrote:
> > В репозиторий-карман autoextra:texlive/Sisyphus
> > http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/
> > выложена текущая сборка импортированного texlive-2014,
> > сборка под Sisyphus/x86_64 и под Sisyphus/i586.
> 
> Не получается поставить.  Вылазят неудовлетворенные зависимости

Спасибо! 
Поторопился с письмом, так как долго от меня не было сообщений.
Надо было еще проверить.
Вечером постараюсь выложить исправленную версию.

-- 

I V

Re: [sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

On Sat, Nov 22, 2014 at 02:19:33AM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > Уважаемые господа,
> > 3) В текущем виде одного большого srpm texlive-2014 в Сизиф не
> > пропихивается. Как решить эту проблему?
> > 
> > У меня есть намерение написать собственный конвертер-генератор
> > tlpobj в srpm. Недостаток такого подхода в том, что в сизиф
> > добавится > 5000 новых srpm, а достоинство в том, что 
> > он позволяет continuous integration, т.е. texlive в Сизифе всегда
> > будет самый свежий и нужда в пересекающихся с texlive 
> > texmf-* пакетах просто отпадет.
> 
> Это повод сделать ещё один компонент наравне с classic и debuginfo и
> делить texmf-* по принципу в classic -- тe texmf-*, которые есть в
> зависимостях у пакетов из classic, а все остальные -- в отдельный
> компонент.

Вручную 5000 пакетов сортировать - это 10 человек надо на одну сортировку,
это, если надо, надо делать автоматически, встроив в incoming -
автоматический вынос листьев дерева зависимостей в подкомпоненту
по критерию.
например, компоненты для Games/*, Development/Java, Development/ ...

-- 

I V

Re: [sisyphus] RoboTeX newsletter III.

[Denis Sergeevich]

Товарищи, а всё-таки, есть смысл сейчас пробовать сборку на p7, или 
лучше на сизифе?
Если я перетяну rpm-build из сизифа, он сильно всё поломает?

p.s. Шикарная новость, спасибо! Но всё-таки смущают эти 5к пакетов.. 
Значит, tlmgr опять оказывается за бортом?

22.11.2014 18:50, Igor Vlasenko пишет:
> On Sat, Nov 22, 2014 at 12:00:54PM +0400, Vladimir Didenko wrote:
>>> В репозиторий-карман autoextra:texlive/Sisyphus
>>> http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/
>>> выложена текущая сборка импортированного texlive-2014,
>>> сборка под Sisyphus/x86_64 и под Sisyphus/i586.
>>
>> Не получается поставить.  Вылазят неудовлетворенные зависимости
>
> Спасибо!
> Поторопился с письмом, так как долго от меня не было сообщений.
> Надо было еще проверить.
> Вечером постараюсь выложить исправленную версию.
>

-- 
С уважением,
Денис

Re: [sisyphus] RoboTeX newsletter III.

[Gleb Fotengauer-Malinovskiy]

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

On Sat, Nov 22, 2014 at 03:48:51PM +0200, Igor Vlasenko wrote:
> On Sat, Nov 22, 2014 at 02:19:33AM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > > Уважаемые господа,
> > > 3) В текущем виде одного большого srpm texlive-2014 в Сизиф не
> > > пропихивается. Как решить эту проблему?
> > > 
> > > У меня есть намерение написать собственный конвертер-генератор
> > > tlpobj в srpm. Недостаток такого подхода в том, что в сизиф
> > > добавится > 5000 новых srpm, а достоинство в том, что 
> > > он позволяет continuous integration, т.е. texlive в Сизифе всегда
> > > будет самый свежий и нужда в пересекающихся с texlive 
> > > texmf-* пакетах просто отпадет.
> > 
> > Это повод сделать ещё один компонент наравне с classic и debuginfo и
> > делить texmf-* по принципу в classic -- тe texmf-*, которые есть в
> > зависимостях у пакетов из classic, а все остальные -- в отдельный
> > компонент.
> 
> Вручную 5000 пакетов сортировать - это 10 человек надо на одну сортировку,
> это, если надо, надо делать автоматически, встроив в incoming -
> автоматический вынос листьев дерева зависимостей в подкомпоненту
> по критерию.

Я имел в виду именно это, естественно, -- автоматическое разделение в
сборочнице.
А критерий достаточно простой получается.

> например, компоненты для Games/*, Development/Java, Development/ ...

Это всё же отдельная тема, от групп все, наоборот, избавляются. Боюсь,
сейчас от них больше проблем.

Я имел в виду только компонент для latex.

-- 
glebfm

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

Re: [sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

On Sat, Nov 22, 2014 at 07:53:38PM +0600, Denis Sergeevich wrote:
> Товарищи, а всё-таки, есть смысл сейчас пробовать сборку на p7, или лучше на
> сизифе?
> Если я перетяну rpm-build из сизифа, он сильно всё поломает?

Чуточку терпения. Как только сборка для сизифа будет обкатана,
я соберу и выложу сборку под p7/t7. 
Пока еще вылезают проблемы со сборкой для сизифа.

Кстати, какая у вас архитектура, i586 или x86_64?
 
> p.s. Шикарная новость, спасибо! Но всё-таки смущают эти 5к пакетов.. Значит,
> tlmgr опять оказывается за бортом?

с позитивной стороны, он просто заменен на более
мощный и универсальный инструмент - rpm+apt.

-- 

I V

Re: [sisyphus] RoboTeX newsletter III.

[Denis Sergeevich]

22.11.2014 23:56, Igor Vlasenko пишет:
> Кстати, какая у вас архитектура, i586 или x86_64?

Есть две машины с x86_64, ещё есть ноут с i586, но там до сих пор p6.

------
С уважением,
Денис

Re: [sisyphus] RoboTeX newsletter III.

[Kirill Maslinsky]

On Fri, Nov 21, 2014 at 07:26:42PM +0200, Igor Vlasenko wrote:
> Уважаемые господа,
> 
> В репозиторий-карман autoextra:texlive/Sisyphus
> http://autoextra.altlinux.org/pub/ALTLinux/texlive/Sisyphus/ 
> выложена текущая сборка импортированного texlive-2014,
> сборка под Sisyphus/x86_64 и под Sisyphus/i586.


Игорь, спасибо!

> Что изменить в текущем полиси 
> и что осталось изменить в texlive-2014.
> --------------------------------------
> 
> 1) хотел бы отказаться от автоматических provides вида 
> texmf(latex/siunitx), поскольку каталоги в ТеХ не играют особой роли,
> 
>  $ kpsepath -w tex siunitx.sty           
> /usr/share/texmf-texlive/tex/latex/siunitx/siunitx.sty
>  $ kpsepath -w tex si-units.cfg          
> /usr/share/texmf-texlive/tex/latex/siunitx/config/si-units.cfg
> 
> и есть прецеденты, когда файлы переезжают в подкаталог/надкаталог,
> сбивая автоматические texmf(...).
> Отсюда следует, что texmf(...) это не инварианты, от них надо
> отказаться, чтобы не создавать проблем, возможно, в пользу файловых
> provides tex(siunitx.sty), tex(si-units.cfg).

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

> мне кажется, что наша схема с fmt.d/ updmap.d/ более надежная.
> Но, c ней есть ряд вопросов.
> 
> есть мысль чтобы уменьшить число конфликтов при обновлении, 
> и руководствуясь /etc полиси, что в /etc не место автогенерированным
> файлам, не предназначенным для редактирования, и
> пользуясь возможностью начать новые полиси с чистого листа.
> можно вынести fmt.d/ updmap.d/ language.d/ для texlive-2014
> в подкаталог в /usr/share/(?)

Но в /usr/share вроде бы тоже не место автогенеренным файлам? Может быть
все-таки что-то вроде /var/lib/texmf/ ?

-- 
KM

Re: [sisyphus] RoboTeX newsletter III.

[Igor Vlasenko]

On Mon, Nov 24, 2014 at 11:05:31AM +0300, Kirill Maslinsky wrote:
> Вариант с файловыми зависимостями выглядит убедительным, тем более что в
> эту модель хорошо укладываются и зависимости не только на пакеты, но и
> на другие ресурсы (шрифты, стили бибтеха и т.п.), которые мы в старом
> полиси просто игнорировали. 

ок, понял.
 
> > мне кажется, что наша схема с fmt.d/ updmap.d/ более надежная.
> > Но, c ней есть ряд вопросов.
> > 
> > есть мысль чтобы уменьшить число конфликтов при обновлении, 
> > и руководствуясь /etc полиси, что в /etc не место автогенерированным
> > файлам, не предназначенным для редактирования, и
> > пользуясь возможностью начать новые полиси с чистого листа.
> > можно вынести fmt.d/ updmap.d/ language.d/ для texlive-2014
> > в подкаталог в /usr/share/(?)
> 
> Но в /usr/share вроде бы тоже не место автогенеренным файлам? Может быть
> все-таки что-то вроде /var/lib/texmf/ ?

У меня не было ясного мнения. 

/var/ это состояние, т.е. если была бы динамическая генерация после установки,
а там статическая.

Внутрь texmf дерева не хочется, чтобы не засорять базы texhash
и mtxrun, особенно учитывая нынешнюю фрагментацию.

/etc/texmf/ ... достаточно логично,
я боялся, что там при обновлении могут остаться остатки старого
texlive-2014 (не на все пакеты есть конфликты), но это не проблема,
конфликты можно добавить.

но /etc/ не хочется засорять. 
Думал что-то вроде /usr/share/texmf-filetrigger/,
но, как показал опыт, в текущей сборке с битым cyrplain
и ругающимся на него filetrigger удобно метить эти файлы как
%config(noreplace), чтобы пользователь мог их править или комментировать.
тогда таки им место в /etc/.



-- 

I V