[devel] abstract TeX dependencies

[Alexey Tourbin]

On Tue, Mar 17, 2009 at 12:57:13PM +0300, Kirill Maslinsky wrote:
> Есть предложение по урегулированию зависимостей для организации
> плавного перехода tetex->texlive, поскольку tetex не поддерживается, 
> а texlive поддерживается и развивается.
> 
> Я вижу тут такие задачи: 
> - необходимо постепенно, но полностью перевести пакеты, использующие
>   ТеХ для сборки, на texlive

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

Для BuildRequires не нужны очень гибкие зависимости.
Как правило, в BuildRequires следует указывать имена настоящих пакетов.
Это то, что делает buildreq.

> - необходимо сделать возможным установку пакетов, по сути независимых
>   от дистрибутива ТеХ, как с tetex, так и с texlive

Это более актуальная задача, потому что tetex и texlive конфликтуют.
Поэтому зависимости Requires должны быть более гибкими.

> Идея в том, что чтобы никого не загонять палками в светлое будущее, 
> нужно сделать выбор того или иного дистрибутива ТеХ максимально гибким.
> 
> Для этого предлагаю организовать виртуальные пакеты, предоставляющие
> обобщённую ТеХовскую функциональность и использовать именно такие 
> обобщённые зависимости в сборочных и установочных заивисимостях пакетов, 
> вместо tetex-* или texlive-*
> 
> Есть варианты, как могут выглядеть такие обобщённые зависимости, хочу
> посоветоваться, какой лучше выбрать:
> 
> 1. /usr/bin/latex, /usr/bin/dvips etc.

Для зависимостей Requires это предпочтительный вариант.
Такие зависимости сейчас генерируются автоматически.

> 	Такие пути автоматически провайдят пакеты, содержащие соотв. бинарники.
> 
> 	В этом случае мы предоставляем apt'у выбирать, какие конкретно
> 	пакеты использовать (из tetex или из texlive),

Не только apt сможет выбирать, но в идеале и пользователь сможет
сменить дистрибутив tex (apt-get install tetex-core- texlive-base).

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

Я ещё не смотрел, как распилен texlive, но у меня есть подозрение, что он
странно распилен, потому что главный пакет с командами получается *-bin
подпакетом.  Тогда возникает вопрос, какой из подпакетов главный, и кто
кого должен требовать.  И чья работоспособность от кого должна зависеть.

> 	apt будет выбирать, кстати, не знаю по какому принципу (лексикографический
> 	порядок?), но сейчас он при прочих равных выберет texlive.

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

> 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.  Но зависимости на файлы (и вообще "хорошие"
зависимости, которые сводятся к файлам) можно искать автоматически,
а зависимости на подсистемы, если они не сводятся к конкретным файлам,
автоматически проставить очень сложно.  А это значит нужно бегать с
палкой за мейнтейнерами и объяснять им где чего нужно написать.

Короче, программа-максимум по части зависимостей, как я её себе
представляю -- мейнтейнер должен запустить buildreq, чтобы зафиксировать
сборочную среду.  Никаких зависимостей вручную указывать не надо --
сборочная среда должна дать приемлемый автоматический результат.

> 	Есть ли какая-то техническая разница между обычными виртуальными
> 	пакетами (см. п. 3) и такими зависимостями (со скобками?)

Давайте определимся, что называть виртуальными пакетами.  Виртуальный
пакет -- это зависимость, у которого нет одноименного *.rpm пакета
(установленного в rpmdb).  В этом смысле зависимости со скобками -- это
как раз виртуальные пакеты, а пакеты типа latex-minimal -- это настоящие
пакеты, потому что они устанавливаются в rpmdb, хотя у них и пустой
список файлов.

> 3. latex-minimal, pdflatex-minimal etc.
> 
> 	Можно сделать такие виртуальные пакеты, в зависимости к которым можно 
> 	поставить эмпирически подобранное множество пакетов, необходимое для
> 	реализации соотв. функции (скажем, сборки документации в стандартном латехе). 
> 
> 	Зависимости виртуальных пакетов можно формировать как в терминах 
> 	конкретных пакетов (texlive-latex-base etc.), так и в терминах более
> 	абстрактных (напр., файловых) зависимостей.

Мне не очень нравятся *-minimal пакеты-пустышки, которые транслируют
зависимости.  Зависимости должны быть непосредственными и конкретными:
если конечному пакету что-то нужно для своей работы, то он должен
содержать непосредственную зависимость в некоем "конкретном" виде.

> PS Кстати, вроде бы упоминалось, что где-то доступны в простом текстовом
> виде актуальные спеки всех пакетов Сизифа, удобные для грепа? 
> Очень бы сейчас пригодилось для выявления пакетов, зависящих от tetex.

Если есть доступ на сервер то спеки извлекаются через rpmpeek.
Упражнение на несколько минут.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?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/20090317/098c34cf/attachment.bin>