[sisyphus] Re: tetex-3.0: файлопомойка разобрана!

[Alexander Bokovoy]

On Mon, May 23, 2005 at 03:07:08PM +0300, Ilia K. wrote:
> > teTeX это один из дистрибутивов TeX-а. Он разделён на две части.
> > В первой части программы из 1 и 5. Во второй вся мощь
> > дистрибутива: пункты 2, 3 и 4. Очевидно, что платформозависимая
> > только первая часть.
> 
> Отлично. Вот эту первую часть и надо собирать в i586.rpm (или что там
> ещё), а всё остальное - в noarch.rpm. Я в spec'ах не силён, но по-моему
> там достаточно переименовать соотв. генерируемые пакеты.
Проблема в том, что есть пересечения между teTeX-data и teTeX-src, в том
смысле, что требуются компоненты первого при сборке архитектурно-зависимых
элементов второго (нет, сгенерированные форматки не являются
архитектурно-независимыми). Поэтому они собираются из одного исходного
пакета и из-за этого нет возможности разделить их на noarch и
arch-specific (в рамках одного spec-файла могут быть пакеты одного типа --
либо архитектурно-зависимые либо архитектурно-независимые).

> > мелкие функционально монолитные кусочки, чтобы пользователь мог
> > сам составить себе необходимую функциональность без лишних
> > файлов. 
> 
> Единственный, по моему мнению плюс этого "дробления" - это экономия
> места при (не)установке пакетов. Учитывая, что мы говорим о teTeX - этот
> плюс весьма сомнительный, так как: 

>* teTeX целиком не такой уж большой по современным меркам (пара сотен
>MB), так что сейчас трудно найти машину, где бы это было проблеммой.
>Современная цена 1Gb на HDD (что намного больше нужд TeX'а) - это 0.5$.
Это существенная проблема для виртуальных серверов, а особенно для
виртуальных сборочных серверов, поскольку для все большего числа пакетов
требуется наличие teTeX для сборки документации из Docbook XML. Чем больше
втягивается в teTeX, тем хуже ситуация с занимаемым местом в виртуальных
сборочных средах -- проблема достаточно актуальная.

> * teTeX любит "разрастаться", создавая кучу файлов в /var/lib/texmf, но
> это только то, что реально использовалось при обрработке документов
> (сгенерированные шрифты например) и рамер инсталляции на это никак не
> влияет.  

> * если всё таки кто-то собирается использовать TeX на очень
> "ограниченной"  машине, то вряд ли ему подойдёт универсальный
> дистрибутив типа teTeX. Скорее всего ему лучше самому поковыряться и
> выбрать по минимуму только то, что необходимо (по схожим причинам пакеты
> в АльтЛинукс собираются для i586 - если вам действительно надо запускать
> программу на i486, найдутся силы и для перекомпиляции).
Зачем сваливать задачу на "самому" в одном из системообразующих пакетов?
К тому же, есть вполне конкретный класс задач, где автоматическая генерация 
образов системы с вполне внятным условиями-ограничениями имеет не только
смысл, но и экономическую необходимость. В таком случае "распиливание"
всех больших _задействованных_ пакетов адекватно поставленной задаче.

> * конечный пользователь TeX'а хочет, чтобы у него "был TeX". То есть,
> поставил пару (а не десяток) пакетов, и всё работает. Лазать по apt-у
> часами в поисках нужного пакета никого не прельщает.  
Эта аргументация аналогична притягиванию "за уши" так называемых "обычных
пользователей". Мы все хотим, чтобы "просто работало", однако это не
означает, что никаких телодвижений при этом выполнить не придется.
Особенно учитывая, что зависимостями между пакетами можно вполне адекватно
организовать такой just-TeX, который можно поставить и он вытянет все за
собой. Это никоим образом не должно служить препятствием решению остальных
задач.


> * для солидных учреждений десяток мегабайт тоже намного дешевле времени
> админа, которому придётся выяснять, почему у Васи Пупкина не
> скомпилировался такой-то файл, какой теховский пакет он требует и,
> наконец, в каком rpm пакете тот пакет искать.
Эти мелочи решаются и должны быть решены упаковщиком на уровне
предоставления виртуальных пакетов-задач. Тот же администратор в солидном
учреждении, раз уж он поддерживает рабочую среду пользователя, может
собрать дополнительный виртуальный пакет, требующий необходимые пакеты.
Для наиболее типовых случаев это будет выполнено упаковщиком в рамках
Сизифа.

> > Один я это не потяну. Я могу собрать из паровоза
> > модернизированный паровоз, но собирать с нуля самолёт я пока не
> > готов.
> 
> Правильно, и не надо. Да и сейчас вы с разбивкой обошлись довольно сурово. Я предлагаю сделать попроще:
> * все бинарики - в что-то вроде tetex-bin.i586.rpm
> * возможно, дополнительные утилиты не требующиеся для обработки tex
> файла вынести в tetex-utils.i586.rpm
> * документация - tetex-doc.noarch.rpm
> * шрифты - tetex-fonts.noarch.rpm (это можно ещё разделить на шрифты
> metafont/type1/чего там ещё, или если большие или конфликтуют/реализуют
> один и тот же шрифт)
> * прочее аппаратно-независимое (типа sty/tex/...) - tetex-files.noarch.rpm
> * можно в отдельные пакеты вынести пару самых больших макропакетов типа
> latex/context, но большой практической пользы в этом я не вижу
> * всякие дополнения, отсутствующие в оригинальном teTeX'е - tetex-addons-*
Нерешаемая задача в рамках RPM из одного SRPM, по причинам, описанным выше.
Предлагаю подумать над тем, как решить эту проблему иным методом, но в
тоже время без переупаковки оригинальных тарболлов на отдельные маленькие
кусочки.

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20050523/95c87081/attachment-0003.bin>