From: Alexey Rusakov <ktirf@altlinux.org> To: devel@lists.altlinux.org Subject: Re: [devel] chkfontpath Date: Thu, 30 Aug 2007 12:23:50 +0400 Message-ID: <20070830122350.2c7c71d4@mission> (raw) In-Reply-To: <200708300944.14898.shrek@altlinux.ru> 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
next prev parent reply other threads:[~2007-08-30 8:23 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-08-28 7:56 [devel] libXfont >= 1.2.9 - прощай chkfontpath Valery V. Inozemtsev 2007-08-28 10:57 ` Valery V. Inozemtsev 2007-08-28 17:01 ` Denis Medvedev 2007-08-28 18:10 ` Valery V. Inozemtsev 2007-08-29 5:26 ` [devel] да здравствует chkfontpath для /etc/X11/fontpath.d Vitaly Lipatov 2007-08-29 5:56 ` Valery V. Inozemtsev 2007-08-29 7:23 ` Alexey Rusakov 2007-08-29 10:15 ` Valery V. Inozemtsev 2007-08-29 13:13 ` Alexey Rusakov 2007-08-29 13:27 ` Valery V. Inozemtsev 2007-08-29 14:41 ` Alexey Rusakov 2007-08-29 17:40 ` Valery V. Inozemtsev 2007-08-29 20:01 ` Vitaly Lipatov 2007-08-30 5:44 ` Valery V. Inozemtsev 2007-08-30 8:23 ` Alexey Rusakov [this message] 2007-08-30 8:46 ` [devel] chkfontpath Alexey Rusakov 2007-08-30 16:23 ` Valery V. Inozemtsev 2007-08-30 16:29 ` Dmitry V. Levin 2007-08-30 16:35 ` Valery V. Inozemtsev 2007-08-30 16:44 ` Dmitry V. Levin 2007-08-30 16:52 ` Valery V. Inozemtsev 2007-08-30 16:44 ` Alexey I. Froloff 2007-08-30 17:17 ` Valery V. Inozemtsev 2007-08-30 17:21 ` Dmitry V. Levin 2007-08-30 17:27 ` Valery V. Inozemtsev 2007-08-30 17:34 ` Dmitry V. Levin 2007-08-31 5:38 ` Valery V. Inozemtsev 2007-08-31 9:34 ` Dmitry V. Levin 2007-08-31 9:49 ` Valery V. Inozemtsev 2007-08-30 17:10 ` Valery V. Inozemtsev 2007-08-31 8:57 ` Хихин Руслан 2007-08-31 9:08 ` Valery V. Inozemtsev 2007-08-31 17:53 ` Хихин Руслан 2007-08-31 18:27 ` Valery V. Inozemtsev 2007-08-31 18:11 ` Хихин Руслан 2007-08-31 19:07 ` Valery V. Inozemtsev 2007-08-31 19:33 ` Хихин Руслан 2007-08-29 9:37 ` [devel] да здравствует chkfontpath для /etc/X11/fontpath.d Slava Semushin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20070830122350.2c7c71d4@mission \ --to=ktirf@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git