[devel] WM resources packaging proposal

[devel] WM resources packaging proposal

[Igor Vlasenko]

Проект полиси по упаковке WM-специфических ресурсов
(menu, .desktop файлов и, возможно, в будущем, других ресурсов).
---------------------------------------------------

1) Вызовы 
%update_menus
%update_desktopdb
%update_wms
 в %post/un пакетов в Сизифе объявить устаревшими.

Вместо этого в 3 пакета: menu, desktop-file-utils, xinitrc 
должны быть упакованы соответствующие posttrans filetriggers.

2) Явные зависимости пакетов с WM-специфическими ресурсами
на пакеты menu и desktop-file-utils объявить устаревшими.

(Обоснование: пакеты (тот же mutt) работающие на без-X-овом сервере,
могут иметь .desktop файлы. при этом на без-X-овом сервере
зависимость на menu/desktop-file-utils явно избыточна.)

Однако зависимости на menu/desktop-file-utils должны где-то
оставаться, иначе эти утилиты вообще ставиться не будут.

Логично, чтобы эти зависимости стояли у пакетов, которые реально
используют меню и desktop_db --- у оконных менеджеров и DE.

Однако, несколько неправильно добавлять туда 
потенциально открытые списки 
Requires: menu desktop-file-utils xinitrc ...
и в %post/un
%update_menus
%update_desktopdb
%update_wms
...

Правильнее их оформить в виде пакета wm-common
(пример у меня в .git + пакет поехал в Daedalus).

Поэтому
3) WM (оконные менеджеры) и DE должны иметь 
Requires: wm-common 
(вытягивает по зависимостям menu desktop-file-utils xinitrc ...)
BuildRequires: rpm-macros-wm-common
и иметь в 
%post
%update_wm

%postun
%clean_wm

соответствующие макросы раскрываются в скрипт %_sbindir/update_wm,
который и вызывает
%update_menus
%update_desktopdb
%update_wms
...

Макрос %update_wm в %post
нужен, чтобы бороться с коллизиями, когда 
posttrans filetriggers устанавливаются одной транзакцией с файлами,
на которые они должны реагировать.

Но в принципе, это зависит от реализации posttrans filetriggers.
Это уже вопрос к Алексею.

Если у Алексея получится так, что установленные _в самой_ транзакции
posttrans filetriggers запускаются на ней наравне с триггерами,
установленными _до_ этой транзакции, тогда этот костыль будет тоже
не нужен.

Уважаемые коллеги, жду ваших отзывов.
Если поддержите, буду продвигать как полиси.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> Проект полиси по упаковке WM-специфических ресурсов
> (menu, .desktop файлов и, возможно, в будущем, других ресурсов).
[...]
> Если у Алексея получится так, что установленные _в самой_ транзакции
> posttrans filetriggers запускаются на ней наравне с триггерами,
> установленными _до_ этой транзакции, тогда этот костыль будет тоже
> не нужен.

Судя по коду, именно так и будет происходить.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Sat, Sep 13, 2008 at 09:34:42PM +0400, Dmitry V. Levin wrote:
> On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> > Проект полиси по упаковке WM-специфических ресурсов
> > (menu, .desktop файлов и, возможно, в будущем, других ресурсов).
> [...]
> > Если у Алексея получится так, что установленные _в самой_ транзакции
> > posttrans filetriggers запускаются на ней наравне с триггерами,
> > установленными _до_ этой транзакции, тогда этот костыль будет тоже
> > не нужен.
> 
> Судя по коду, именно так и будет происходить.

Замечательно.
Тогда, резюмируя, суть предложения --- выбросить все %post
и Requires:, а взамен прописать 
Requires: wm-common в каждом WM/DE.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Michael Shigorin]

On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> Если поддержите, буду продвигать как полиси.

Вроде резонно.  На (веб-)сервере действительно две проблемы,
хотя главная из них -- скорее развесистые зависимости IM...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] WM resources packaging proposal

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

В Сбт, 13/09/2008 в 20:57 +0300, Igor Vlasenko пишет:
> On Sat, Sep 13, 2008 at 09:34:42PM +0400, Dmitry V. Levin wrote:
> > On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> > > Проект полиси по упаковке WM-специфических ресурсов
> > > (menu, .desktop файлов и, возможно, в будущем, других ресурсов).
> > [...]
> > > Если у Алексея получится так, что установленные _в самой_ транзакции
> > > posttrans filetriggers запускаются на ней наравне с триггерами,
> > > установленными _до_ этой транзакции, тогда этот костыль будет тоже
> > > не нужен.
> > 
> > Судя по коду, именно так и будет происходить.
> 
> Замечательно.
> Тогда, резюмируя, суть предложения --- выбросить все %post
> и Requires:, а взамен прописать 
> Requires: wm-common в каждом WM/DE.
Мне нравится, поддерживаю.

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

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Евгений Терешков]

Igor Vlasenko пишет:

> Замечательно.
> Тогда, резюмируя, суть предложения --- выбросить все %post
> и Requires:, а взамен прописать 
> Requires: wm-common в каждом WM/DE.

Тогда на это нужен тест repocop (потяжелее) и желательно simple migration
howto на вики.

Вообще предложение выглядит неплохо. Если где-то будет жать - поправим.

-- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru

Re: [devel] WM resources packaging proposal

[Kirill A. Shutemov]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> Правильнее их оформить в виде пакета wm-common
> (пример у меня в .git + пакет поехал в Daedalus).

Когда этот пакет планируется отправить в сизиф? Я как раз занимаюсь
упаковкой awesome.

-- 
Regards,  Kirill A. Shutemov
 + Belarus, Minsk
 + ALT Linux Team, http://www.altlinux.com/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Thu, Sep 18, 2008 at 12:36:43PM +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> > Правильнее их оформить в виде пакета wm-common
> > (пример у меня в .git + пакет поехал в Daedalus).
> 
> Когда этот пакет планируется отправить в сизиф? Я как раз занимаюсь
> упаковкой awesome.

думал отправить в сизиф как только в rpm появятся 
реализованные Алексеем posttrans filetriggers.
как я понимаю, в 4.0.4-alt96.5 их нет.

Впрочем, как я понимаю, posttrans filetriggers в Сизифе
будут обязательно, поэтому, действительно, можно и
выложить заранее.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Thu, Sep 18, 2008 at 01:32:00PM +0800, Евгений Терешков wrote:
> Igor Vlasenko пишет:
> 
> > Замечательно.
> > Тогда, резюмируя, суть предложения --- выбросить все %post
> > и Requires:, а взамен прописать 
> > Requires: wm-common в каждом WM/DE.
> 
> Тогда на это нужен тест repocop (потяжелее) и желательно simple migration
> howto на вики.

Пока еще некуда мигрировать.

надо сначала дождаться, пока в Сизифе появятся 
реализованные Алексеем posttrans filetriggers.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Thu, Sep 18, 2008 at 12:36:43PM +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> > Правильнее их оформить в виде пакета wm-common
> > (пример у меня в .git + пакет поехал в Daedalus).

Пакет wm-common, по-моему, можно не делать.  Насколько я понимаю, любой
window manager кладёт файл в /etc/X11/wmsession.d, и поэтому у него уже есть
зависимость на каталог /etc/X11/wmsession.d, а этот каталог принадлежит
пакету xinitrc.  В пакете xinitrc также находится скрипт /usr/sbin/update_wms.
Отстаётся запаковать триггер в пакет xinitrc, тогда никакие дополнительные
зависимости в window manager пакетах будут не нужны.

> Когда этот пакет планируется отправить в сизиф? Я как раз занимаюсь
> упаковкой awesome.

Когда будет готово!

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> Проект полиси по упаковке WM-специфических ресурсов
> (menu, .desktop файлов и, возможно, в будущем, других ресурсов).

[...]

> Но в принципе, это зависит от реализации posttrans filetriggers.
> Это уже вопрос к Алексею.
> 
> Если у Алексея получится так, что установленные _в самой_ транзакции
> posttrans filetriggers запускаются на ней наравне с триггерами,
> установленными _до_ этой транзакции, тогда этот костыль будет тоже
> не нужен.

Все какие есть /usr/lib/rpm/*.filetrigger запускаются в конце
транзакции, в том числе если они были добавлены во время самой
транзакции.

Только тут есть тонкость: если в этой же самой транзакции впервые
обновляется rpm (устанавливается новая версия с поддержкой триггеров),
то триггеры не запустятся (потому что транзакцию отрабатывает старый
rpm).  Тогда для некоторых пакетов хотелось бы автоматически выставить
pre-зависимость на rpm с поддержкой триггеров.  Но этого на самом деле
никак нельзя сделать: в моем дизайне триггеры -- это черный ящик, они
получают на вход полный список файлов, и, возможно, что-то делают.
То есть "регулярные выражения", которые сидят в триггерах, непрозрачны;
имея на руках пакет, мы не может заранее (автоматически) сказать, какие
триггеры отработают, и нужен ли rpm с поддержкой триггеров или нет.

> Уважаемые коллеги, жду ваших отзывов.
> Если поддержите, буду продвигать как полиси.

Я не понял только одного: по какому условию должен срабатывать триггер
для %update_wms.  Я сначала думал, что по условию /etc/X11/wmsession.d/*,
но чтение скриптов update_wms и runwm меня скорее озадачило.

И вообще, что должен делать %update_wms?  Только не в общих словах,
а конкретно, в деталях, что должно происходить при установке или
обновлении window manager?

Полиси должно быть пронизано конкретным пониманием всех проблем. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Thu, Sep 18, 2008 at 06:30:16PM +0000, Alexey Tourbin wrote:
> On Thu, Sep 18, 2008 at 12:36:43PM +0300, Kirill A. Shutemov wrote:
> > On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> > > Правильнее их оформить в виде пакета wm-common
> > > (пример у меня в .git + пакет поехал в Daedalus).
> 
> Пакет wm-common, по-моему, можно не делать.  Насколько я понимаю, любой
> window manager кладёт файл в /etc/X11/wmsession.d, и поэтому у него уже есть
> зависимость на каталог /etc/X11/wmsession.d, а этот каталог принадлежит
> пакету xinitrc.  В пакете xinitrc также находится скрипт /usr/sbin/update_wms.
> Отстаётся запаковать триггер в пакет xinitrc, тогда никакие дополнительные
> зависимости в window manager пакетах будут не нужны.

а меню, а update-desktop-db, a update-mime-info, a [еще что-то нужно будет]?
набор зависимостей для window manager не сводится в xinitrc.

смысл wm-common -- что это псевдоним для открытого списка зависимостей.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

On Fri, Sep 19, 2008 at 01:13:05AM +0300, Igor Vlasenko wrote:
> On Thu, Sep 18, 2008 at 06:30:16PM +0000, Alexey Tourbin wrote:
> > On Thu, Sep 18, 2008 at 12:36:43PM +0300, Kirill A. Shutemov wrote:
> > > On Sat, Sep 13, 2008 at 08:22:41PM +0300, Igor Vlasenko wrote:
> > > > Правильнее их оформить в виде пакета wm-common
> > > > (пример у меня в .git + пакет поехал в Daedalus).
> > 
> > Пакет wm-common, по-моему, можно не делать.  Насколько я понимаю, любой
> > window manager кладёт файл в /etc/X11/wmsession.d, и поэтому у него уже есть
> > зависимость на каталог /etc/X11/wmsession.d, а этот каталог принадлежит
> > пакету xinitrc.  В пакете xinitrc также находится скрипт /usr/sbin/update_wms.
> > Отстаётся запаковать триггер в пакет xinitrc, тогда никакие дополнительные
> > зависимости в window manager пакетах будут не нужны.
> 
> а меню, а update-desktop-db, a update-mime-info, a [еще что-то нужно будет]?
> набор зависимостей для window manager не сводится в xinitrc.
> 
> смысл wm-common -- что это псевдоним для открытого списка зависимостей.

Давайте это обсудим.  Идея триггера в том, что, получая на вход список
установленных/обновленных/удаленных файлов, он может выполнять некоторое
действие.  Но шаблон для имени файлов не является единственным критерием --
триггер может делать fs lookup (собственно, чтобы определить, был ли
файл установлен/обновлен или же удален) и что-то ещё.

Нужна спецификация, что именно должны делать конкретные триггеры и при
каких условиях.  Триггер от /etc/X11/wmsession.d отличается от триггера
/usr/lib/menu.  Они могут быть запакованы в разных пакетах -- xinitrc
и menu соответственно.

Допустим, что при изменении чего-либо в /etc/X11/wmsession.d надо также
обновлять menu.  Тогда мы имеем как бы неполные (точнее, "нелокальные")
спецификации триггеров -- надо вызывать update_menus надо даже тогда, когда
ничего не меняется в /usr/lib/menu.  Тогда, в принципе, триггер wmseesion.d
может выполнять два действия: основное (по факту задействования триггера)
и дополнительное ("нелокальное" по задействованию).  То есть триггер
wmsession.d может группировать в себе два вызова: update_wms и
update_menus.  Тогда либо в пакете xinitrc появится зависимость на menu
(и любой window manager будет автоматически вытягивать menu), либо эту
зависимость можно сделать условной: [ -x /usr/bin/update-menus ] и т.п.
В последнем случае у пакета xinitrc не будет зависимости на menu (что
вроде бы хорошо), но установка window manager уже не будет автоматически
вытягивать menu (что вроде бы плохо).

Значит, имеет место быть общий вопрос правильного "распределения"
зависимостей в иерархии пакетов.  По-моему, "открытый список зависимостей"
wm-common пока не нужен, а нужно продумать иерархию зависимостей исходя
из спецификации (которой нет), что должно происходить в общем случае.

То есть, грубо говоря, в %post-скриптах были понатырканы всякие
вызовы update-тры-ты-ты на всякий случай.  Теперь можно ещё раз
подумать, как должно быть правильно.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

On Fri, Sep 19, 2008 at 05:17:36AM +0000, Alexey Tourbin wrote:
> > > Пакет wm-common, по-моему, можно не делать.  Насколько я понимаю, любой
> > > window manager кладёт файл в /etc/X11/wmsession.d, и поэтому у него уже есть
> > > зависимость на каталог /etc/X11/wmsession.d, а этот каталог принадлежит
> > > пакету xinitrc.  В пакете xinitrc также находится скрипт /usr/sbin/update_wms.
> > > Отстаётся запаковать триггер в пакет xinitrc, тогда никакие дополнительные
> > > зависимости в window manager пакетах будут не нужны.
> > 
> > а меню, а update-desktop-db, a update-mime-info, a [еще что-то нужно будет]?
> > набор зависимостей для window manager не сводится в xinitrc.
> > 
> > смысл wm-common -- что это псевдоним для открытого списка зависимостей.
> 
> Давайте это обсудим.  Идея триггера в том, что, получая на вход список
> установленных/обновленных/удаленных файлов, он может выполнять некоторое
> действие.  Но шаблон для имени файлов не является единственным критерием --
> триггер может делать fs lookup (собственно, чтобы определить, был ли
> файл установлен/обновлен или же удален) и что-то ещё.
> 
> Нужна спецификация, что именно должны делать конкретные триггеры и при
> каких условиях.  Триггер от /etc/X11/wmsession.d отличается от триггера
> /usr/lib/menu.  Они могут быть запакованы в разных пакетах -- xinitrc
> и menu соответственно.

Спецификация триггера должна включать в себя:
- шаблон имени файлов
- дополнительные условия срабатывания триггера
- команда/действие, выполняемое триггером
- состояние системы до срабатывания триггера
- состояние системы после срабатывания триггера

(Только это должны быть не детсадовские объяснения, что дескать,
до запуска триггера меню находится в старом состоянии, а после запуска
триггера мы имеем обновленное меню, а конкретные -- что именно должно
измениться в menu на уровне представления данных.)

Window manager'ы, которые поддерживают menu, кладут специальный файл
в /etc/menu-methods.  Значит, можно обеспечить зависимость на каталог
/etc/menu-methods.  Тогда в триггере wmsession.d специально обрабатывать
меню не надо, а menu триггер должен срабатывать по двум шаблонам:
/usr/lib/menu (для приложений) /etc/menu-methods (для window manager'ов).

Значит, для menu мы уже двигаемся ближе к спецификации.
А как обстоит дело с update-desktop-db?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Fri, Sep 19, 2008 at 05:17:36AM +0000, Alexey Tourbin wrote:
> > > Отстаётся запаковать триггер в пакет xinitrc, тогда никакие дополнительные
> > > зависимости в window manager пакетах будут не нужны.
> > 
> > а меню, а update-desktop-db, a update-mime-info, a [еще что-то нужно будет]?
> > набор зависимостей для window manager не сводится в xinitrc.
> > 
> > смысл wm-common -- что это псевдоним для открытого списка зависимостей.
> 
> Давайте это обсудим.  
Идея триггера в том, что, получая на вход список
[skipped]
согласен 100%
 
> Допустим, что при изменении чего-либо в /etc/X11/wmsession.d надо также
> обновлять menu.  

А здесь вы меня не поняли.
Никаким образом не имелось в виду, что wm-common связан с filetriggers.

Уточню мысль.
Пусть %post menu,update-desktop-database и т.д. переехали на filetriggers.

Предлагаю не только убить эти %post вызовы в пакетах, но и пойти дальше:
Убить явные зависимости на update-desktop-database, menu и  т.д. 
в обычных пакетах.

Пример.
Сервер. java. в пакете есть .desktop файлы для меню и для
обработки mime-типа java-jar. Ранее при наличии таких
файлов предлагалось ставить явную зависимость на
ту же update-desktop-database.

Теперь предлагается Убить явные зависимости.
Бонус -- компактнее серверная инсталляция.

Грабли --- если никто явно не требует menu,update-desktop-database и т.д.
то их может просто не оказаться в установленной системе.

Поэтому кто-то их все-таки должен требовать.
Кто? Логически думая -- WM/DE. они потребители
всех этих desktop-database, mime-database, generated menus, etc.

Вот и предлагается весь список и вытягивать 
через 1 пакет wm-common. Это удобно тем, что если
изменится внутренняя кухня, пакеты пересобирать не надо.

В отличие от явного прописывания списка в каждый DE/WM.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Fri, Sep 19, 2008 at 05:48:21AM +0000, Alexey Tourbin wrote:
> > Пакет wm-common, по-моему, можно не делать.  Насколько я понимаю, любой
> > window manager кладёт файл в /etc/X11/wmsession.d, и поэтому у него уже есть
> > зависимость на каталог /etc/X11/wmsession.d, а этот каталог принадлежит
> > пакету xinitrc.  В пакете xinitrc также находится скрипт /usr/sbin/update_wms.
> > Отстаётся запаковать триггер в пакет xinitrc, тогда никакие дополнительные
> > зависимости в window manager пакетах будут не нужны.

Если сказать по другому, то зависимость wm-common на xinitrc
избыточная, так как она должна прописываться автоматически.

> Window manager'ы, которые поддерживают menu, кладут специальный файл
> /etc/menu-methods.  Значит, можно обеспечить зависимость на каталог
> /etc/menu-methods.  

Если сказать по другому, то зависимость wm-common на menu
можно сделать избыточной, так как ее можно прописывать автоматически.

> Тогда в триггере wmsession.d специально обрабатывать
> меню не надо, 

там меню в любом случае обрабатывать не надо.

а menu триггер должен срабатывать по двум шаблонам:
> /usr/lib/menu (для приложений) /etc/menu-methods (для window manager'ов).

необходимо и достаточно по /usr/lib/menu.

> Значит, для menu мы уже двигаемся ближе к спецификации.
+1

> А как обстоит дело с update-desktop-db?
хуже. это независимая утилита, которая сбрасыват 
результат работы в /usr/share/applications/mimeinfo.cache.

А кто будет mimeinfo.cache пользоваться, неизвестно.
скрипту UTSL не скажешь.

Если сказать по другому, то зависимость wm-common 
на update-desktop-db по существу.

то же самое, похоже, насчет update-mime-database.
зависимость wm-common на нее похоже тоже не автоматизировать.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2867 bytes --]

On Fri, Sep 19, 2008 at 11:18:25AM +0300, Igor Vlasenko wrote:
> > Допустим, что при изменении чего-либо в /etc/X11/wmsession.d надо также
> > обновлять menu.  
> 
> А здесь вы меня не поняли.
> Никаким образом не имелось в виду, что wm-common связан с filetriggers.
> 
> Уточню мысль.
> Пусть %post menu,update-desktop-database и т.д. переехали на filetriggers.
> 
> Предлагаю не только убить эти %post вызовы в пакетах, но и пойти дальше:
> Убить явные зависимости на update-desktop-database, menu и  т.д. 
> в обычных пакетах.

Конечно.  Зависимости должны выставляться автоматически.
Для update_wms и update_menus есть хороший способ выставлять
автоматические зависимости.

1) Если window manager кладёт файл (регистрируется) в
/etc/X11/wmsession.d, то через зависимость на каталог
/etc/X11/wmsession.d будет вытягиваться пакет xinitrc,
в котором также будет запакован триггер %update_wms.

2) Если менеджер поддреживает традиционную систему меню,
то он кладёт файл в /etc/menu-methods/$WM_NAME, и через зависимость
на каталог /etc/menu-methods будет вытягиваться пакет menu,
в котором также будет запакован триггер %update_menus.

Некоторые менеджеры (в частности, wmii, который я использую)
не поддерживают традиционную систему меню; они не кладут файл
в /etc/menu-methods/$WM_NAME, поэтому они не получат лишнюю
зависимость на пакет menu.

Пока всё чисто.

> Пример.
> Сервер. java. в пакете есть .desktop файлы для меню и для
> обработки mime-типа java-jar. Ранее при наличии таких
> файлов предлагалось ставить явную зависимость на
> ту же update-desktop-database.
> 
> Теперь предлагается Убить явные зависимости.
> Бонус -- компактнее серверная инсталляция.

Как быть с update-desktop-database?  В пакетах-приложениях зависимость
на update-desktop-database, конечно же, вообще не нужна, а только в
window manager'ах, которые поддерживают desktop database.

Некоторые window manager'ы не поддерживают desktop database,
и зависимость на update-desktop-database для них будет лишней.

> Грабли --- если никто явно не требует menu,update-desktop-database и т.д.
> то их может просто не оказаться в установленной системе.
> 
> Поэтому кто-то их все-таки должен требовать.
> Кто? Логически думая -- WM/DE. они потребители
> всех этих desktop-database, mime-database, generated menus, etc.
> 
> Вот и предлагается весь список и вытягивать 
> через 1 пакет wm-common. Это удобно тем, что если
> изменится внутренняя кухня, пакеты пересобирать не надо.
> 
> В отличие от явного прописывания списка в каждый DE/WM.

Получается, что, вообще говоря, разные window manager'ы могут
поддерживать разные списки desktop фич.  Зависимости должны быть
прозрачными и поддаваться автоматическому поиску, а если непрозрачны
и не поддаются автоматическому поиску, то нужно их гранулированно
указывать вручную.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

On Fri, Sep 19, 2008 at 11:36:25AM +0300, Igor Vlasenko wrote:
>> а menu триггер должен срабатывать по двум шаблонам:
>> /usr/lib/menu (для приложений) /etc/menu-methods (для window manager'ов).
> необходимо и достаточно по /usr/lib/menu.

Если установлен новый wm, который поддерживает меню, то нужно запустить
update_menus, чтобы он сгенерировал меню для нового manager'а.

> > А как обстоит дело с update-desktop-db?
> хуже. это независимая утилита, которая сбрасыват 
> результат работы в /usr/share/applications/mimeinfo.cache.

Вообще-то генерация генерата в /usr/share является не очень хорошей
идеей, особенно если генерат не является функцией каталога, в котором
он находится.  Этот вопрос мы замнём. :)

> А кто будет mimeinfo.cache пользоваться, неизвестно.
> скрипту UTSL не скажешь.
> 
> Если сказать по другому, то зависимость wm-common 
> на update-desktop-db по существу.

Сомнительно.  Получается, что wm-common -- это фантомный пакет,
который содержит набор зависимостей для некоторых "десктопных" wm.

> то же самое, похоже, насчет update-mime-database.
> зависимость wm-common на нее похоже тоже не автоматизировать.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

On Fri, Sep 19, 2008 at 08:59:59AM +0000, Alexey Tourbin wrote:
> > Если сказать по другому, то зависимость wm-common 
> > на update-desktop-db по существу.
> 
> Сомнительно.  Получается, что wm-common -- это фантомный пакет,
> который содержит набор зависимостей для некоторых "десктопных" wm.

В споре рождается истина :)
(Подумав). Действительно, неправильно позиционировать этот 
список как wm-common. Но этот список есть реальная сущность. 

Теперь я наверное сам понял.
Этот список стандартных фич согласно freedesktop.org.
Его правильно назвать freedesktop-common.

Этот список открыт, поскольку freedesktop.org постоянно 
добавляет стандарты.

Список этих зависимостей должен стоять у каждого DE/WM/FM,
который грозится быть freedesktop compliant.


> Получается, что, вообще говоря, разные window manager'ы могут
> поддерживать разные списки desktop фич.  Зависимости должны быть
> прозрачными и поддаваться автоматическому поиску, а если непрозрачны
> и не поддаются автоматическому поиску, то нужно их гранулированно
> указывать вручную

IMHO, freedesktop-common правильнее, чем гранулированно
указывать вручную, так как бульдозер прогресса тащит все эти
DE/WM/FM к поддержке всего списка.
Они обязаны (стандарт требует) поддерживать все, 
и если даже чего-то не далают, то быстро начнут.

А майнтайнер может элементарно проморгать, что в релизе X.Y
поддержки такой-то не было, а в релизе X.Y+1 уже 
появилась.


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] WM resources packaging proposal

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3634 bytes --]

On Fri, Sep 19, 2008 at 12:30:01PM +0300, Igor Vlasenko wrote:
> On Fri, Sep 19, 2008 at 08:59:59AM +0000, Alexey Tourbin wrote:
> > > Если сказать по другому, то зависимость wm-common 
> > > на update-desktop-db по существу.
> > 
> > Сомнительно.  Получается, что wm-common -- это фантомный пакет,
> > который содержит набор зависимостей для некоторых "десктопных" wm.
> 
> В споре рождается истина :)
> (Подумав). Действительно, неправильно позиционировать этот 
> список как wm-common. Но этот список есть реальная сущность. 
> 
> Теперь я наверное сам понял.
> Этот список стандартных фич согласно freedesktop.org.
> Его правильно назвать freedesktop-common.

А сколько всего таких десктопов есть?
На ум приходят три штуки: gnome, kde и xfce.  

> Этот список открыт, поскольку freedesktop.org постоянно 
> добавляет стандарты.
> 
> Список этих зависимостей должен стоять у каждого DE/WM/FM,
> который грозится быть freedesktop compliant.

Зависимости должны быть конкретны.  Я даже исхожу из того, что все
зависимости по сути конкретны.  Например, если кто-то слинковался с
библиотекой libfoo, то будет конкретная зависимость на libfoo.so.0,
а если кто-то требует файл /foo/bar, то можно указать зависимость на
/foo/bar (зависимость на имя пакета уже является менее конкретной).

Так вот, все зависимости конкретны, но не все зависимости прозрачны,
и не все зависимости поддаются автоматическому поиску.  Зависимости
на menu прозрачны, а зависимости на update-desktop-db уже непрозрачны.

Но зависимости на update-desktop-db всё ещё можно считать конкретными.
Что на самом деле нужно WM/DE?  Ему нужен этот самый desktop db, а этот
desktop db существует в виде конкретных файлов.  Так что можно
проставить зависимость на /usr/share/applications/mimeinfo.cache.
(Остаётся правильно сгруппировать файлы "на другом конце", чтобы
эта связка хорошо работала.)  То есть какой-то бинарик в WM/DE загружает
этот mimeinfo.cache, просто такую зависимость очень трудно вытянуть из
бинарика автоматически.

А freedesktop-common уже не является конкретной зависимостью,
он, наоборот, является "фантомным" пакетом (нельзя получить естественную
зависимость на freedesktop-common, исходя из содержимого этого пакета).
Он предлагает механизм переходных зависимостей: пакет A по сути требует
пакет C, но эта зависимость непрозрачна; вместо этого пакет A требует
пакет B, который в свою очередь требует C (то есть в пакете B
перечислены все непрозрачные зависимости пакета A).

> > Получается, что, вообще говоря, разные window manager'ы могут
> > поддерживать разные списки desktop фич.  Зависимости должны быть
> > прозрачными и поддаваться автоматическому поиску, а если непрозрачны
> > и не поддаются автоматическому поиску, то нужно их гранулированно
> > указывать вручную
> 
> IMHO, freedesktop-common правильнее, чем гранулированно
> указывать вручную, так как бульдозер прогресса тащит все эти
> DE/WM/FM к поддержке всего списка.

С одной стороны, все зависимости по сути являются конкретными,
и тогда переходных зависимостей быть не должно (и тогда никаких
"реальных сущностей" тоже нет :).

С другой стороны, не все зависимости прозрачны; если freedesktop-common
в этом отношении окажется полезным в энном количестве случаев, тогда
надо его сделать.  Только в понятие полезности нужно заранее заложить
минимальное значение N.

> Они обязаны (стандарт требует) поддерживать все, 
> и если даже чего-то не далают, то быстро начнут.
> 
> А майнтайнер может элементарно проморгать, что в релизе X.Y
> поддержки такой-то не было, а в релизе X.Y+1 уже 
> появилась.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] WM resources packaging proposal

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Twas brillig at 10:50:12 19.09.2008 UTC+00 when at@altlinux.ru did gyre and gimble:

 AT> А сколько всего таких десктопов есть?
 AT> На ум приходят три штуки: gnome, kde и xfce.  

e17 coming soon (tm)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [devel] WM resources packaging proposal

[Eugene Ostapets]

2008/9/19 Alexey Tourbin <at altlinux.ru>:
> On Fri, Sep 19, 2008 at 12:30:01PM +0300, Igor Vlasenko wrote:
>> Теперь я наверное сам понял.
>> Этот список стандартных фич согласно freedesktop.org.
>> Его правильно назвать freedesktop-common.
>
> А сколько всего таких десктопов есть?
> На ум приходят три штуки: gnome, kde и xfce.
Еще есть lxde, который быстро развивается... Да и многие другие
проекты заявлвяют о поддержке fd.o

-- 
С уважением,
Евгений Остапец
uin: 23747217
jid: eugene_ostapets@jabber.ru

Re: [devel] WM resources packaging proposal

[Igor Vlasenko]

AT> А сколько всего таких десктопов есть?
AT> На ум приходят три штуки: gnome, kde и xfce.  
 
MG> e17 coming soon (tm)

EO> Еще есть lxde, который быстро развивается... 
EO> Да и многие другие проекты заявлвяют о поддержке fd.o

еще, например, Сизифные EDE, Rox.

в общем, переименовал в freedesktop-common
и засылаю в Дедал.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine