[devel] chkfontpath

[Alexey Rusakov]

On Thu, 30 Aug 2007 09:44:10 +0400
Valery V. Inozemtsev wrote:

> > Вряд ли вы не представляете объём знаний (причём различных на
> > разных этапах развития системы), который требуется для того,
> > чтобы упаковать шрифтовой пакет. Значит просто прикидываетесь.
> > Ручную пересборку затевать приходится только из-за того, что
> > рутинный труд по упаковке шрифтов не был минимизирован ранее с
> > помощью макросов.
> 
> макросы это зло, почему я уже объяснил выше
Это было объяснение не того, что макросы зло, а того, что макросы должны
определяться в пакетах с минимально необходимым для их использования
набором зависимостей. Например, в rpm-build-*

> > Ну кто не будет, а кто будет.
> > Я вообще против триггеров в пакетах, посколько их редко
> > используют и соответственно их редко создают без ошибок.
+1

> поэтому я и предлагаю дать мне NMU на все шрифтовые пакеты
Я пока не готов дать NMU на fonts-ttf-dejavu для подобного изменения.
Семеро одного не ждут, и менять все шрифтовые пакеты из-за того, что не
хочется изменить два, являющиеся источником перемен, я считаю
нецелесообразным.

> > Чем плоха возможность вызова chkfontpath или аналога, который
> > будет производить необходимые изменения.
> 
> во первых лишняя сущность, во вторых аналога нет
freedesktop2menu тоже лишняя сущность. До сих пор, по-моему, в каких-то
пакетах вызывается. Никто из-за этого не дёргается.

Между прочим, меня попросили придумать способ обойтись без триггеров и
пообещали поблагодарить за это. То есть понимание того, что триггеры - зло
(имхо, гораздо бОльшее чем макросы, но это имхо), вроде бы есть. Я
придумал этот способ, но вместо благодарности вижу неприятие. shrek@, для
вас триггеры меньшее зло, чем макросы?

-- end-of-flame

Давайте от эмоций перейдём к конструктиву. Начнём с общего, надеюсь,
очевидного тезиса: пакет, содержащий новый /etc/X11/fs/config
(xorg-x11-xfs?), должен содержать конфликт на (старый) chkfontpath. Если
есть возражения против этого, высказывайте.
Коль скоро это так, наличие старого chkfontpath в системе автоматически
означает, что /etc/X11/fs/config _нужно_ обновлять по старинке.

Дальше имеем несколько способов решения одной и той же проблемы. 

1. Пропатчить chkfontpath (патч будет) на предмет поддержки нового
синтаксиса. Убрать или сделать опциональным вызов chkfontpath
из rpm-build-fonts и шрифтовых пакетов, использующих его явно.
Достоинства - сохраняется старый интерфейс добавления/удаления шрифтов в
системе. Это же является и недостатком - в системе остаётся привидение в
виде больше-не-нужного chkfontpath, которое застрянет в репозитории на
неопределённое время.
2. Пересобрать шрифтовые пакеты и rpm-build-fonts, убрав оттуда вызов
chkfontpath, добавить триггер, охраняющий /etc/X11/fs/config нового
образца (куда добавить и каким образом он будет охранять этот файл?),
позже убрать chkfontpath из репозитория. Достоинство - при наличии всех
необходимых ингредиентов переход репозитория (не пользователей) на новые
рельсы произойдёт быстро. Недостатки - использование триггера (который,
так же как и chkfontpath в первом варианте, остаётся в репозитории на
неопределённое время), необходимость массовой пересборки пакетов;
проблемы для пользователей, поскольку chkfontpath больше нет, а
установленные у них шрифтовые пакеты по-прежнему требуют его наличия.
3. Сделать опциональным (либо через 'test -x', либо через '|| :') вызов
chkfontpath в макросах %post_fonts и %postun_fonts, убрать либо сделать
опциональным вызов chkfontpath из тех шрифтовых пакетов, которые не
используют rpm-build-fonts. Пересобрать все шрифтовые пакеты. После этого
убрать сам chkfontpath из репозитория. Достоинство - пользователи ничего
не заметят. Недостаток - необходимость массовой пересборки пакетов,
проблемы для пользователей, аналогичные предыдущему пункту.

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

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team