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. Упражнение на несколько минут.