[devel] abstract TeX dependencies
Kirill Maslinsky
=?iso-8859-1?q?kirill_=CE=C1_altlinux=2Eorg?=
Ср Мар 18 19:43:17 MSK 2009
On Tue, Mar 17, 2009 at 03:29:06PM +0300, Alexey Tourbin wrote:
> On Tue, Mar 17, 2009 at 12:57:13PM +0300, Kirill Maslinsky wrote:
> > Есть предложение по урегулированию зависимостей для организации
> > плавного перехода tetex->texlive, поскольку tetex не поддерживается,
> > а texlive поддерживается и развивается.
> >
> > Я вижу тут такие задачи:
> > - необходимо постепенно, но полностью перевести пакеты, использующие
> > ТеХ для сборки, на texlive
>
> Это менее актуальная задача. Пока существуют tetex и texlive,
> достаточно, чтобы пакет собирался в одной из конфигураций.
> Переход на сборку с texlive должен выполнить мейнтейнер.
Согласен. Тогда эта задача снимается, что всем упрощает жизнь.
> > - необходимо сделать возможным установку пакетов, по сути независимых
> > от дистрибутива ТеХ, как с tetex, так и с texlive
>
> Это более актуальная задача, потому что tetex и texlive конфликтуют.
> Поэтому зависимости Requires должны быть более гибкими.
> > 1. /usr/bin/latex, /usr/bin/dvips etc.
>
> Для зависимостей Requires это предпочтительный вариант.
> Такие зависимости сейчас генерируются автоматически.
ОК. Значит ли это, что если пакет просто использует какие-то
программы из ТеХа, а не является частью самого дистрибутива ТеХа,
то следует удалить из установочных зависимостей tetex-* и texlive-* ?
Могут ли быть случаи, в которых нужно явное указание зависимости
вида /sr/bin/latex ?
> > Такие пути автоматически провайдят пакеты, содержащие соотв. бинарники.
> >
> > В этом случае мы предоставляем apt'у выбирать, какие конкретно
> > пакеты использовать (из tetex или из texlive),
>
> Не только apt сможет выбирать, но в идеале и пользователь сможет
> сменить дистрибутив tex (apt-get install tetex-core- texlive-base).
В том смысле, что при смене tetex на texlive апт не вынесет все
зависимые пакеты? Так да, за это и боремся :)
> > допуская, что
> > пакет, содержащий исполняемый файл, напр. latex, будет содержать
> > также и всё необходимое для "стандартной" компиляции.
>
> Я ещё не смотрел, как распилен texlive, но у меня есть подозрение, что он
> странно распилен, потому что главный пакет с командами получается *-bin
> подпакетом. Тогда возникает вопрос, какой из подпакетов главный, и кто
> кого должен требовать. И чья работоспособность от кого должна зависеть.
Распилено почти так же, как в дебиане. Мне тоже распил кажется
неоптимальным, готов выслушать обоснованные предложения.
Сейчас по факту подсистему LaTeX предоставляет пакет texlive-latex-base,
он вытягивает texlive-base-bin и texlive-base, без которых латех
полноценно работать не будет.
> > apt будет выбирать, кстати, не знаю по какому принципу (лексикографический
> > порядок?), но сейчас он при прочих равных выберет texlive.
>
> Если нет интуитивного понятного и очевидного способа, какой из вариантов
> должен быть выбран, то не следует полагаться на apt, что он найдёт и
> предложит именно такой способ.
Ну, в общем, я не против того, чтобы апт вёл себя как сейчас и выбирал
при прочих равных texlive :)
>
> > 2. tex(latex), tex(pdflatex) etc.
> >
> > Вместо автоматически полученных файловых зависимостей, можно сделать
> > другие абстрактные зависимости, более точно описывающие заявленную
> > функциональность.
>
> Что означает зависимость tex(latex)? "Хорошие" зависимости, как
> правило, сводятся к файлам. Если сведение зависимости к файлу не
> создает двусмысленности, то это предпочтительный вариант. Если же
> появляется двусмысленность, то используется пространство имён со
> скобками, напр. perl(File/Find.pm), это означает, что файл File/Find.pm
> может находиться в одном из нескольких стандартных каталогов.
> Другой пример: для сонеймов стандартный каталог просто отрезается.
>
> Если речь идёт о latex, то здесь есть двусмысленность по пакетам (tetex
> vs texlive), но нет двусмысленности по пути -- /usr/bin/latex. Поэтому
> лучше всего использовать путь к файлу как основную форму зависимости,
> если речь идёт о программе "latex".
>
> Другое дело, если речь идёт не просто о программе "latex", а о
> подсистеме latex. Но зависимости на файлы (и вообще "хорошие"
> зависимости, которые сводятся к файлам) можно искать автоматически,
> а зависимости на подсистемы, если они не сводятся к конкретным файлам,
> автоматически проставить очень сложно. А это значит нужно бегать с
> палкой за мейнтейнерами и объяснять им где чего нужно написать.
Да, проще, конечно, обеспечить, чтобы пакет, предоставляющий
/usr/bin/latex, всегда предоставлял полноценную подсистему LaTeX,
а не просто голый бинарник. Наверное, даже стоит принять это за правило
и записать в полиси.
[...]
> > 3. latex-minimal, pdflatex-minimal etc.
> >
> > Можно сделать такие виртуальные пакеты, в зависимости к которым можно
> > поставить эмпирически подобранное множество пакетов, необходимое для
> > реализации соотв. функции (скажем, сборки документации в стандартном латехе).
> >
> > Зависимости виртуальных пакетов можно формировать как в терминах
> > конкретных пакетов (texlive-latex-base etc.), так и в терминах более
> > абстрактных (напр., файловых) зависимостей.
>
> Мне не очень нравятся *-minimal пакеты-пустышки, которые транслируют
> зависимости. Зависимости должны быть непосредственными и конкретными:
> если конечному пакету что-то нужно для своей работы, то он должен
> содержать непосредственную зависимость в некоем "конкретном" виде.
ОК, от этого варианта отказываемся.
> > PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> > виде актуальные спеки всех пакетов Сизифа, удобные для грепа?
> > Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.
>
> Если есть доступ на сервер то спеки извлекаются через rpmpeek.
> Упражнение на несколько минут.
Ага, спасибо, попробую.
--
Kirill Maslinsky
ALT Linux Team
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип : application/pgp-signature
Размер : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20090318/b7fdff81/attachment.bin>
Подробная информация о списке рассылки Devel