[devel] О сборке программ на GTK / GNOME

[devel] О сборке программ на GTK / GNOME

[Vitaly Lipatov]

По результатам переписки разработчиков ALT Linux Team
составлены советы по упаковке программ GTK, GNOME и KDE.

Почему в pkg-config отключена рекурсия
======================================

Рекурсивный сбор --libs в принципе не нужен, более того -- 
вреден, 
хотя бы потому что является источником огромного числа лишних
зависимостей, которые потом должен обрабатывать apt и rpm

Если программа не линкуется с какой-либо библиотекой, то весьма
вероятно, что это ошибка в сборке библиотеки - библиотека
использует функции из других библиотек, но с ними не слинкована.
Ошибка эта практически везде, кроме как 
в ALT Linux прикрыта стандартным поведением pkg-config.


Файлы информации о mime-типах
=============================

В этих файлах хранится описание форматов файлов
(их mime-type, комментарием, способом определения принадлежности 
к 
формату по MAGIC value и шаблону...)

1. Если в пакете есть файлы /usr/share/mime/packages/*.xml,
то при его установке, удалении, обновлении необходимо
обновить и кеш базы mime-типов с использованием в spec-файле 
макросов 
%update_mimedb и %clean_mimedb.

То есть в спеке должны быть секции:
%post
%update_mimedb

%postun
%clean_mimedb

И указаны зависимости:
Requires(post,postun): shared-mime-info >= 0.15-alt2

2. Файлы из каталога
%_datadir/mime-info/* 
не используется GNOME-программами, которые получают
mime-информацию из пакета shared-mime-info.

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

Файлы schemas
=============
При сборке в пакете установку schemas надо отключать:
%configure --disable-schemas-install

В спеке должны быть секции:
%post
%gconf2_install %name

%preun
if [ $1 = 0 ]; then
%gconf2_uninstall %name
fi

в качестве параметров к %gconf2-(un)unstall может
быть указано несколько названий.

Образец оформления секции %files:

%config %_sysconfdir/gconf/schemas/*

В зависимостях пакета должно быть:
Requires(post): GConf2
BuildPreReq: GConf2

Файлы scrollkeeper
==================

Нельзя упаковывать каталог и файлы из 
%_localstatedir/scrollkeeper,
если они получаются при сборке, их надо удалить командой

%__rm -rf %buildroot%_var/lib/scrollkeeper

в секции %install

В спеке должны быть секции:
%post
%update_scrollkeeper

%postun
%clean_scrollkeeper


В зависимостях пакета должно быть:
Requires(post,postun): scrollkeeper

Если %make_install вызывает scrollkeeper-update и 
сборка прерывается по ошибке - перед %make_install
нужно сделать
export OMF_DIR=%buildroot%_var/lib/scrollkeeper


Поиск файлов локализации - %find_lang
====================================

%find_lang вызывается в секции %install

Для программ GNOME указывается:
%find_lang --with-gnome %name

При этом find-lang кроме файлов переводов в %_datadir/locale ищет 
файлы 
справки Гном в %_datadir/gnome/help и .omf файлы в %_datadir/omf

Поэтому не нужно указывать в секции %files каталоги с locale, а 
также
%_datadir/omf/%name
%_datadir/gnome/help/


Для программ KDE указывается:
%find_lang --with-kde %name

При этом find-lang ищет файлы справки KDE в %_docdir/HTML

Далее секция %files оформляется следующим образом:
%files -f %name.lang


Файлы меню
===========

Файл меню либо создаётся непосредственно заданием
его содержимого, либо формируется.
Как правило программа содержит файл .desktop,
из него можно получить файл меню следующей командой
в разделе %install:

freedesktop2menu.pl %name "Путь разделов меню" \
    %buildroot%_datadir/applications/%name.desktop \
    %buildroot%_menudir/%name

При использовании этого скрипта в пакете
должна быть указана зависимость:
BuildPreReq: menu-devel

Каталог для файлов меню обычно создают командой:
%__mkdir_p %buildroot%_menudir

Созданный файл меню устанавливается в каталог %_menudir.
При установке или удалении пакета меню должно переформироваться,
для этого в спеке должны быть секции:

%post
%update_menus

%postun
%clean_menus

В секции %files:

%_menudir/*
%_datadir/applications/*
и возможно
%_datadir/application-registry/*


Обновление базы данных по меню
==============================

В файлах desktop обычно хранится информация о том, какие
форматы способна обрабатывать та или иная программа.

это нужно только в случае если в %_datadir/applications/*.desktop 
есть 
$ grep -i mime //usr/share/applications/*.desktop
MimeType=application/postscript;

В спеке должны быть секции:
%post
%update_desktopdb

%postun
%clean_desktopdb

В пакете должна быть указана зависимость:
Requires(post,postun): desktop-file-utils
BuildPreReq: desktop-file-utils

Используется вне зависимости от типа программы в пакете,
и всегда должно быть указано.


Файлы bonobo
============

Пока ничего не знаю кроме того, что в %files пишется
%_libdir/bonobo/servers/*

Установка файлов
================

В секции %install для установки файлов используется либо строка
%make_install install DESTDIR=%buildroot
(в случае если используется схема Makefile с DESTDIR)
либо
%makeinstall
(она задаёт prefix и остальные пути по типу
prefix=/home/lav/tmp/%{name}-buildroot/usr)

Это для программ, которые не пытаются запоминать пути,
куда их устанавливают, при установке, а делают это
при configure

Примеры использования
=====================

Смотрите в Сизифе пакеты
ggv2, rythmbox, eog2, gthumb, totem
conglomerate, inkscape 

    
"Yuri N. Sedunov" <aris@altlinux.ru>, 2004
Vitaly Lipatov <lav@altlinux.ru>, 2004

09.11.2004

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] О сборке программ на GTK / GNOME

[Dmitry V. Levin]

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

On Wed, Nov 10, 2004 at 02:22:27AM +0300, Vitaly Lipatov wrote:
> По результатам переписки разработчиков ALT Linux Team
> составлены советы по упаковке программ GTK, GNOME и KDE.
> 
> Почему в pkg-config отключена рекурсия
> ======================================
> 
> Рекурсивный сбор --libs в принципе не нужен, более того -- 
> вреден, 
> хотя бы потому что является источником огромного числа лишних
> зависимостей, которые потом должен обрабатывать apt и rpm

А также может увеличивать объём памяти, выделяемой под запуск программ,
и время запуска программ.

> Если программа не линкуется с какой-либо библиотекой, то весьма
> вероятно, что это ошибка в сборке библиотеки - библиотека
> использует функции из других библиотек, но с ними не слинкована.
> Ошибка эта практически везде, кроме как 
> в ALT Linux прикрыта стандартным поведением pkg-config.

> "Yuri N. Sedunov" <aris@altlinux.ru>, 2004
> Vitaly Lipatov <lav@altlinux.ru>, 2004

Я так понимаю, что это следует включить в alt-packaging?


-- 
ldv

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

[devel] Re: О сборке программ на GTK / GNOME

[Michael Shigorin]

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

On Wed, Nov 10, 2004 at 02:36:36AM +0300, Dmitry V. Levin wrote:
> Я так понимаю, что это следует включить в alt-packaging?

Угу.

2 lav: уважаю!

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

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

Re: [devel] Re: О сборке программ на GTK / GNOME

[Vitaly Lipatov]

On Wednesday 10 November 2004 12:34, Michael Shigorin wrote:
> On Wed, Nov 10, 2004 at 02:36:36AM +0300, Dmitry V. Levin 
wrote:
> > Я так понимаю, что это следует включить в alt-packaging?
>
> Угу.
В каком формате туда принимают? В docbook?

> 2 lav: уважаю!
2 mike: Спасибо Юрию, из ответов которого на мои глупые вопросы
практически и было составлено...

-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Re: О сборке программ на GTK / GNOME

[Mikhail Zabaluev]

В Срд, 10/11/2004 в 23:27 +0300, Vitaly Lipatov пишет:
> > 2 lav: уважаю!
> 2 mike: Спасибо Юрию, из ответов которого на мои глупые вопросы
> практически и было составлено...

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

Re: [devel] Re: О сборке программ на GTK / GNOME

[Kirill Maslinsky]

Добрый день!

> > > Я так понимаю, что это следует включить в alt-packaging?
> >
> > Угу.
> В каком формате туда принимают? В docbook?
В Мастере есть пакет alt-doc-devel: это немного переработанные 
и дополненные ALT Packaging HOWTO и ALT Mantainer HOWTO -- из них 
получилась небольшая кнжика, которая сейчас называется 
"ALT Linux Team и проект Sysiphus". Было бы идеально, если текст 
про упаковку GNOME-приложений вписался бы туда как раздел. 

Принимаем в любом формате, предпочитаем plain text, не предпочитаем 
OpenOffice. 

Кстати, к Андрею Орлову: тексты про упаковку модулей Питона и программ
на Питоне (очень толковые и нужные) были бы в этой же книжке как нельзя
более кстати. Как, собственно, и описание всех гласно и негласно 
существующих в Сизифе policy.

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

[devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Mikhail Zabaluev]

В Чтв, 11/11/2004 в 11:16 +0300, Kirill Maslinsky пишет:
> 
> Кстати, к Андрею Орлову: тексты про упаковку модулей Питона и программ
> на Питоне (очень толковые и нужные) были бы в этой же книжке как нельзя
> более кстати. Как, собственно, и описание всех гласно и негласно 
> существующих в Сизифе policy.

Это мне напомнило:
https://bugzilla.altlinux.org/show_bug.cgi?id=4796

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Andrey Orlov]

On Thursday 11 November 2004 11:11, Mikhail Zabaluev wrote:
> > Кстати, к Андрею Орлову: тексты про упаковку модулей Питона и программ
> > на Питоне (очень толковые и нужные) были бы в этой же книжке как нельзя
> Это мне напомнило:
> https://bugzilla.altlinux.org/show_bug.cgi?id=4796

Каждый из нас считает себя правым, а серьезных аргументов нет ни у одной стороны.
Кстати, файлы я переименовал. 


-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Mikhail Zabaluev]

В Чтв, 11/11/2004 в 15:17 +0300, Andrey Orlov пишет:
> > > Кстати, к Андрею Орлову: тексты про упаковку модулей Питона и программ
> > > на Питоне (очень толковые и нужные) были бы в этой же книжке как нельзя
> > Это мне напомнило:
> > https://bugzilla.altlinux.org/show_bug.cgi?id=4796
> 
> Каждый из нас считает себя правым, а серьезных аргументов нет ни у одной стороны.

Про то, что нужно сделать книжку в DocBook и включить ее в alt-docs,
говорю уже не только я. Поймите меня правильно, дело вовсе не в
спортивной правоте.

[devel] Re: ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Michael Shigorin]

On Fri, Nov 12, 2004 at 04:58:08AM +0300, Mikhail Zabaluev wrote:
> Про то, что нужно сделать книжку в DocBook и включить ее в
> alt-docs, говорю уже не только я. Поймите меня правильно, дело
> вовсе не в спортивной правоте.

Сделайте.

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

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Andrey Orlov]

On Friday 12 November 2004 04:58, Mikhail Zabaluev wrote:
> В Чтв, 11/11/2004 в 15:17 +0300, Andrey Orlov пишет:
> > > > Кстати, к Андрею Орлову: тексты про упаковку модулей Питона и программ
> > > > на Питоне (очень толковые и нужные) были бы в этой же книжке как нельзя
> > > Это мне напомнило:
> > > https://bugzilla.altlinux.org/show_bug.cgi?id=4796
> > 
> > Каждый из нас считает себя правым, а серьезных аргументов нет ни у одной стороны.
> 
> Про то, что нужно сделать книжку в DocBook и включить ее в alt-docs,
> говорю уже не только я. Поймите меня правильно, дело вовсе не в
> спортивной правоте.

Ну так займитесь. Исходники документации открыты. Поймите меня правильно - дело вовсе не в спортивной 
правоте, работа по поддержке пакетов дело сугубо добровольное и я действительно не имею возможности
поддерживать доку в докбук. Я один раз попробовал - на документации к Zope - и в общем-то этого напряга не выдержал.
В том числе и потому, что самый частый вопрос, который я видел у себя в почтовом ящике - чем эту "№;%" прочитать и нельзя ли
ее у меня получить в виде текста.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Kirill Maslinsky]

Добрый день!

> > Про то, что нужно сделать книжку в DocBook и включить ее в alt-docs,
> > говорю уже не только я. Поймите меня правильно, дело вовсе не в
> > спортивной правоте.
> 
> Ну так займитесь. Исходники документации открыты. Поймите меня правильно - дело вовсе не в спортивной 
> правоте, работа по поддержке пакетов дело сугубо добровольное и я действительно не имею возможности
> поддерживать доку в докбук. Я один раз попробовал - на документации к Zope - и в общем-то этого напряга не выдержал.
> В том числе и потому, что самый частый вопрос, который я видел у себя в почтовом ящике - чем эту "???;%" прочитать и нельзя ли
> ее у меня получить в виде текста.

Андрей, я предлагаю Вам включить и поддерживать в alt-docs@ Вашу документацию 
в том формате, который Вас устраивает, как я понимаю, это ST. 

В docs@ уже был разговор о том, что нужно организовать репозиторий ``исходных текстов'' документации, в котором авторы могли бы поддерживать свои тексты 
в актуальном состоянии в любом удобном им формате. Преобразование текстов 
этого репозитория в DocBook, редактура, подготовка книжек и пакетов, а также отслеживание изменений, сделанных авторами _в этом репозитории_ -- это, 
собственно, уже задачи участников проекта DOCS. 

Надеюсь что Вам, как автору, будет несложно обновлять свою документацию ещё в одном месте (это можно даже автоматизировать). Нам будет гораздо проще в этом случае отследить изменения и вовремя обновить документацию, чем следить за обновлением каждого продукта и сопровождающих его текстов. 

Если Вы согласитесь на такой способ взаимодействия -- я готов немедленно
заняться организацией такого репозитория. Думаю, дальнейшее обсуждение этого 
вопроса стоит перенести в docs@, Вы подписаны на эту рассылку?

Предложения и замечания по организации ``репозитория исходных текстов документации'' необходимы и будут очень кстати в рассылке docs@. 

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Andrey Orlov]

On Friday 12 November 2004 13:50, Kirill Maslinsky wrote:
> > Ну так займитесь. Исходники документации открыты. Поймите меня правильно - дело вовсе не в спортивной 
> > правоте, работа по поддержке пакетов дело сугубо добровольное и я действительно не имею возможности
> > поддерживать доку в докбук. Я один раз попробовал - на документации к Zope - и в общем-то этого напряга не выдержал.

> Надеюсь что Вам, как автору, будет несложно обновлять свою документацию ещё в одном месте (это можно даже автоматизировать).

Чего уж проще: rpm -Uvh rpm-build-python;  cvs commit; 
:)

> Нам будет гораздо проще в этом случае отследить изменения и вовремя обновить документацию, чем следить за обновлением 
> каждого продукта и сопровождающих его текстов.   

Хорошо. Как я уже писал - в принципе я согласен.

> Если Вы согласитесь на такой способ взаимодействия -- я готов немедленно
> заняться организацией такого репозитория. Думаю, дальнейшее обсуждение этого 
> вопроса стоит перенести в docs@, Вы подписаны на эту рассылку?

Да, я подписан на рассылку, и когда-то даже у меня был доступ в CVS. Я попробую проверить жив ли еще этот
доступ и помню ли я пароли.

> Предложения и замечания по организации ``репозитория исходных текстов документации'' необходимы и будут очень кстати в рассылке docs@. 

Я пока предложений высказывать не буду, хочу только получить ответы на неск. вопросов, часть из которых навеяна прошлым опытом:

1. Если у нас уже какая-либо практика ведения в док буке именно ПОЛИСИ на пакетирование? Вопрос задан потому,
что есть несколько характерных особенностей, которые я заметил по крайней мере на своей практике, и мне бы хотелось понять,
как это будет решаться.

2. Будут ли документы полиси опубликованы где-л. в общедоступном месте? Особенност вопроса в том, что многие документы
постоянно обновляются, и их обновление должно незамедлительно публиковаться. На тьекущий момент - все доки сбраны в одном месте,
в пакете rpm-build-python - все решается просто. Если в инет будет выкладыватся версия полугодовой давности - вреда будет больше чем пользы.
Вопрос даже не в том, что информация может перестать быть валидной - это для полиси не характерно - вопрос в том, что полиси не содержащая
последние (наиболее актуальные) изменения будет создавать потребителю ложную видимость знакомства с полиси.

3. Как будут решаться вопросы с литературной правкой? Чгря даже на случае с Zope у меня были некоторые проблемы, а то была все-таки
более менее старательно написанная документация, тогда как в случае с полиси литературность я однозначно приношу в жертву оперативности
обновления и однозначности текста. 

4. Python-полиси содержит явные и неявные ссылки на другую аналогичную документацию, в частности из пакета rpm/rpm-build. Будет ли
эта документация поддерживаться там же (может быть, уже поддерживается)?

5. Как будет решаться вопрос с версиями, а самое главное - с паралельными ветвями полиси? Сейчас версия полиси лежит в пакете rpm-build-python
и возможность установки и использования этого пакета примерно совпадает с границами применимости полиси, это, может быть, не совсем
удобно, зато  управляемо, объяснимо и воспроизводимо.

В любом случае, я прошу, до тех пор, пока эта технология не будет обкатана, что бы на видном месте 
стояло следующие замечание: "это неофициальная версия полиси, которая, возможно, искажена или устарела. 
Официальная версия содержится в пакете rpm-build-python"
 
-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Kirill Maslinsky]

Доброе, уже, наверное, утро.


> > Надеюсь что Вам, как автору, будет несложно обновлять свою документацию ещё в одном месте (это можно даже автоматизировать).
> 
> Чего уж проще: rpm -Uvh rpm-build-python;  cvs commit; 
> :)

Этот разговор я хотел бы продолжить в docs@, куда и направляю копию, 
но если кто-то из тех подписчиков devel@, кто не читает docs@, 
захочет что-нибудь добавить или откомментировать, пожалуйста, 
не стесняйтесь это делать и здесь. 

> > Предложения и замечания по организации ``репозитория исходных текстов документации'' необходимы и будут очень кстати в рассылке docs@. 
> 
> Я пока предложений высказывать не буду, хочу только получить ответы на неск. вопросов, часть из которых навеяна прошлым опытом:
> 
> 1. Если у нас уже какая-либо практика ведения в док буке именно ПОЛИСИ на пакетирование? Вопрос задан потому,
> что есть несколько характерных особенностей, которые я заметил по крайней мере на своей практике, и мне бы хотелось понять,
> как это будет решаться.

Пока единственное полиси в докбуке -- alt-packaging, которое я обновил 
по новой версии текста от Димы Левина перед выходом ALM 2.4. 
Так что нет практики. Поскольку сборник полиси по проекту Sisyphus всё
равно нужен, такую практику придётся создавать.

> 2. Будут ли документы полиси опубликованы где-л. в общедоступном месте? Особенност вопроса в том, что многие документы
> постоянно обновляются, и их обновление должно незамедлительно публиковаться. На тьекущий момент - все доки сбраны в одном месте,
> в пакете rpm-build-python - все решается просто. Если в инет будет выкладыватся версия полугодовой давности - вреда будет больше чем пользы.
> Вопрос даже не в том, что информация может перестать быть валидной - это для полиси не характерно - вопрос в том, что полиси не содержащая
> последние (наиболее актуальные) изменения будет создавать потребителю ложную видимость знакомства с полиси.

Все документы из пакетов alt-docs-* скоро таки будут опубликованы на сайте 
docs.altlinux.ru, и там будут всегда последние версии. Сейчас последние 
версии документов представлены в Сизифе в пакетах alt-docs-*.

Если удастся хорошо организовать систему обновлений документации, так что
участники проекта docs сразу и непосредственно будут узнавать о выходе новой
версии полиси, то обновление текста в DocBook и выкладывание в сеть -- дело
техники. Перечисленные выше причины, пожалуй, свидетельствуют за то, чтобы
объявить обновление полиси (т. е. пакета alt-docs-devel) приоритетной задачей.
Это будет оправданно, если этот пакет действительно будет востребован, как 
отражающий текущее состояние разработки в Сизифе: как справочник для опытных
и руководство для начинающих. Пока мне кажется, что так и должно произойти.

> 3. Как будут решаться вопросы с литературной правкой? Чгря даже на случае с Zope у меня были некоторые проблемы, а то была все-таки
> более менее старательно написанная документация, тогда как в случае с полиси литературность я однозначно приношу в жертву оперативности
> обновления и однозначности текста. 

Для литературной правки есть отличный момент перехода текста из авторского
варианта в DocBook. Можно и нужно делать не только разметку текста, но и
редактуру (так, впрочем, почти всегда и происходит). Серьёзная проблема,
которой я пока не могу предложить никакого практического решения -- как потом
обратно вносить редактуру в авторский текст? Если сразу править именно исходный
вариант, предоставленный автором, то всё равно потом придётся дублировать
изменения в DocBook. Но, конечно, и автору нет смысла пренебрегать чаще
полезной, чем вредной литературной и прочей правкой. 

> 4. Python-полиси содержит явные и неявные ссылки на другую аналогичную документацию, в частности из пакета rpm/rpm-build. Будет ли
> эта документация поддерживаться там же (может быть, уже поддерживается)?

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

README.ALT из rpm -- интегрирована с alt-packaging в том же пакете 
alt-docs-devel (там тексты несколько пересекались). Раз уж оно туда 
попало, то поддерживаться будет. Если получится схема поддержки 
полиси, rpm policy тоже будет поддерживаться по этой схеме. 
Про документацию из rpm-build я просто не знаю -- вопрос к Вам и к авторам: 
что из этого имеет отношение к Сизифу и нужно в alt-docs-devel?  
Будем включать.

> 5. Как будет решаться вопрос с версиями, а самое главное - с паралельными ветвями полиси? Сейчас версия полиси лежит в пакете rpm-build-python
> и возможность установки и использования этого пакета примерно совпадает с границами применимости полиси, это, может быть, не совсем
> удобно, зато  управляемо, объяснимо и воспроизводимо.
> 
> В любом случае, я прошу, до тех пор, пока эта технология не будет обкатана, что бы на видном месте 
> стояло следующие замечание: "это неофициальная версия полиси, которая, возможно, искажена или устарела. 
> Официальная версия содержится в пакете rpm-build-python"

А если в начале каждого полиси, опубликованного в alt-docs-devel, поставить обязательную краткую справку: к какой версии соответствующего продукта этот 
текст относится, какой он имеет статус (пробный, предложение, обязательный
и общепринятый, устаревающий и т. п.), и также _какие ещё_ версии существуют
наряду с ним, _где_ и _с каким статусом_). 

Поскольку это один абзац в начале текста, при смене позиций (например, смене
статуса текущего опубликованного документа с общепринятого на устаревший 
и под.) -- обновление его в online-версии alt-docs-devel можно сделать 
_очень оперативно_. Это не предполагает, что нужно сразу разметить в 
DocBook и опубликовать новую версию полиси, на что нужно время. Нужно только,
чтобы автор позаботился об обновлении одного абзаца о статусе текста. 

Мне такой вариант представляется гораздо более информативным, чем оговорка
о возможной (но необязательной) неадекватности документа. Более того, он 
позволяет предавать гласности спорные предложения, не дожидаясь единогласия
(которое может и не наступить) и при этом никого не вводя в заблуждение 
относительно их статуса: просто нужно оговорить, что перед читателем -- 
предложение. Разработка, в конце концов, это поиск, и документация 
должна это отражать.

При всем alt-docs-devel я готов в начале поставить объяснение его статуса: 
отражает текущее состояние разработки, поэтому если Вы хотите знать наверняка --
не полагаётесь на печатную версию или пакет в дистрибутиве, смотрите последнюю 
версию в Сизифе или на сайте. 

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Andrey Orlov]

On Saturday 13 November 2004 02:52, Kirill Maslinsky wrote:
> > 3. Как будут решаться вопросы с литературной правкой? Чгря даже на случае с Zope у меня были некоторые проблемы, а то была все-таки
> > более менее старательно написанная документация, тогда как в случае с полиси литературность я однозначно приношу в жертву оперативности
> > обновления и однозначности текста. 
> 
> Для литературной правки есть отличный момент перехода текста из авторского
> варианта в DocBook. Можно и нужно делать не только разметку текста, но и
> редактуру (так, впрочем, почти всегда и происходит). Серьёзная проблема,
> которой я пока не могу предложить никакого практического решения -- как потом
> обратно вносить редактуру в авторский текст? Если сразу править именно исходный
> вариант, предоставленный автором, то всё равно потом придётся дублировать
> изменения в DocBook. Но, конечно, и автору нет смысла пренебрегать чаще
> полезной, чем вредной литературной и прочей правкой. 

Тут есть два момента. Во-1-ых, вы сами сказали, как возвращать редактуру в исходный
текст - неясно. Собственно одна из проблем, которые у меня встали при работе с Docbook в прошлый
раз - это то, что текст в докбуке даже после моих небольших усилий по его разметке, перестал
быть читабельным. Когда туда начали добавлятся более-менее серьезные усилия специалистов, я просто
перестал ориентироваться в тексте и его обновление стало очень мучительным (у меня довольно
страннное восприятие текста, я помню сформатированный текст чисто зрительно очень большими кусками,
и за счет этого легко в нем ориентируюсь и быстро позиционируюсь в нужном месте: но текст для этого должен быть
более-менее аккуратно сформатирован, иначк узнаваемость теряется - в постоянном "шуме" ориентироаться
невозможно; цитаты исходного кода с заменами < > на &lt; &gt; уничтожили один 
из основных ориентиров (код я помню лучше, чем пояснения к нему), кроме того, я легко выхватываю из 
текста ключевые слова (там Zope, Python) когда их тоже стали заменять на
&altlinux; в общем, для меня настал крындец). Я долгое время думал, что это моя личная проблема, но
вот на недавнем линуксфесте узнал, что проблема достаточно общая.

Сама литературная правка, знаете ли, тоже. С бытующей в рашн-комьюити политикой пафосного отношения к документации -
когда оттуда удаляются все мало-мальски скользкие и личные выражения, сленг и все остальное, после чего из него
начисто пропадает все ощущение автора - я не согласен категорически. И не думаю, что  мне кто-то сможет объяснить,
почему мой текст, составленный в т.ч. и после того, как я ознакомился с неким прототипом (и возможно не одним), составленном
в достаточно игривой манере (на английском языке, правда), должен становится нудным, тухлым и тусклым документом
со сложноподчиненными выражениями на три страницы в его русской интерпретации.  В общем, по-моему тут происходит
явная подмена науки наукообразием. Другая, столь же острая проблема (особенно в отношении Полиси), это перевод 
терминов. Может быть, кому-то после этого текст становится понятным.  Но тем, для кого он писался, и даже тому 
__кем__ он писался текст перестает быть понятен абсолютно. 

Насколько я готов включать результат такой правки в текст - я, честно говоря, не знаю.  Иногда меня удается убедить. 

> > 4. Python-полиси содержит явные и неявные ссылки на другую аналогичную документацию, в частности из пакета rpm/rpm-build. Будет ли
> > эта документация поддерживаться там же (может быть, уже поддерживается)?
> 
> Честно говоря, лучше все неявные ссылки сделать явными. 
> Уверен, что это во всех случаях возможно и в подавляющем большинстве -- 
> полезно.

Для этого их нужно позиционировать. Для этого нужно чбы было общедоступное место,
в котором эта документация гарантировано есть. Иными словами, нужно чбы коллекция 
полиси была замкнутой и мне не нужно было описывать "как поскипать (например) поиск зависимостей
в каталоге /usr/share/doc", зная, что это описано в таком-то месте другой полиси. В текущей ситуации
это боле-менее срабатывает для rpm (-build?) (там где Димина дока про макросы), в остальных случаях
ситуация хуже. Даже от участвующих в текущем треде людей я пару раз получал отсылки к документации,
якобы формализующей то-то и се-то, документация была - а вот ни малейшего упоминания того-то и сего-то
 - не было.

> > 5. Как будет решаться вопрос с версиями, а самое главное - с паралельными ветвями полиси? 
> > Сейчас версия полиси лежит в пакете rpm-build-python 
> > и возможность установки и использования этого пакета примерно совпадает с границами 
> > применимости полиси, это, может быть, не совсем 
> > удобно, зато  управляемо, объяснимо и воспроизводимо.

> А если в начале каждого полиси, опубликованного в alt-docs-devel, поставить обязательную краткую справку:
> к какой версии соответствующего продукта этот  

Как бы еще обязать читателя ее прочитывать? Знаете, я работал над одной книжечкой старательно протестировал
все примеры и выписал там же все номера версий использованноег софта и т.д. т.п. Через два года после издания
посыпались жалобы читателей что книга "ужасна" так как "ни один" пример не работает. Объяснение очень простое:
за два года сменились мажоры подавляющего большинства продуктов. А вспомнил я это как пример отношения
читателей  к таким комментариям. Конечно, я всегда могу отмазаться, показав комментарий - но потребителю от этого
не легче.

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

Я не случайно сказал про ветви. Так сложилось (и я считаю что это правильно  рад тому, что хотя бы в одном случае это удалось сложить),
у нас почти всегда активны минимум две ветви полиси: в дедале и в сизифе. В дедале типа действщая модель в натуральную 
величину.

> При всем alt-docs-devel я готов в начале поставить объяснение его статуса: 
> отражает текущее состояние разработки, поэтому если Вы хотите знать наверняка --
> не полагаётесь на печатную версию или пакет в дистрибутиве, смотрите последнюю 
> версию в Сизифе или на сайте. 

Да, конечно. По крайней мере первое время.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Kirill Maslinsky]

Добрый день!

Прошу прощения за задержку с ответом, не хотел отвечать наспех.

> > Если сразу править именно исходный
> > вариант, предоставленный автором, то всё равно потом придётся дублировать
> > изменения в DocBook. Но, конечно, и автору нет смысла пренебрегать чаще
> > полезной, чем вредной литературной и прочей правкой. 
> 
> Тут есть два момента. Во-1-ых, вы сами сказали, как возвращать редактуру в исходный
> текст - неясно. Собственно одна из проблем, которые у меня встали при работе с Docbook в прошлый
> раз - это то, что текст в докбуке даже после моих небольших усилий по его разметке, перестал
> быть читабельным. 

Итак, это довод в пользу того, чтобы делать всякую редактуру и корректуру в том 
же формате, в котором прислал текст автор. Но и в этом случае будут проблемы с 
синхронизацией с DocBook.

Вариант 1: автор предоставляет текст, редактор что-то правит, автор принимает или не принимает правку, и так пока они не договорятся, _после этого_ текст
размечается в DocBook. Получается длинный редакторский цикл (минус) и хороший текст (плюс). Если потом автор предоставил новую версию текста -- 
хо-хо! -- задачка для редактора отследить все изменения (хорошо, если автор пишет в plain text, а если в OOo!), внести необходимую правку в эти изменения,
договориться с автором и _внести_ нужные изменения в DocBook. Мучительно 
хочется упростить кропотливую работу по отслеживанию и внесению изменений. 
Проблемы бы не было, если бы процесс преобразования в DocBook был
автоматическим, но, но...

Вариант 2: автор предоставляет текст, редактор _сразу_ размечает его в DocBook, 
после чего правит авторский и DocBook вариант параллельно (что ужасно), либо 
автоматически вносит все изменения из докбука в авторский или наоборот (что возможно?). Получается, что сразу есть непроверенного качества текст в докбуке, причём качество текста улучшается по мере прохождения редакторского цикла, и он в любом срезе технически доступен для публикации (плюс), но как избежать двойной ручной работы редактора? (минус, и пребольшой). Если автор потом 
предоставит новую версию текста, см. вариант 1.

> Сама литературная правка, знаете ли, тоже. С бытующей в рашн-комьюити политикой пафосного отношения к документации -
> когда оттуда удаляются все мало-мальски скользкие и личные выражения, сленг и все остальное, после чего из него
> начисто пропадает все ощущение автора - я не согласен категорически. И не думаю, что  мне кто-то сможет объяснить,
> почему мой текст, составленный в т.ч. и после того, как я ознакомился с неким прототипом (и возможно не одним), составленном
> в достаточно игривой манере (на английском языке, правда), должен становится нудным, тухлым и тусклым документом
> со сложноподчиненными выражениями на три страницы в его русской интерпретации.

Дабы вести разговор о правке конкретно, я перечёл документацию из rpm-build-python, и посмотрел, что бы мне хотелось в ней изменить при публикации в 
книжке alt-docs-devel. 

Там есть опечатки, есть недостающие знаки препинания, есть пара грамматических 
несогласованностей. Наверное, Вы не станете возражать, что всё это полезно 
исправить перед публикацией, да и вообще полезно исправить. Есть слово "чбы", 
которое я бы, грешным делом, заменил на "чтобы", хоть оно и яркий маркер 
авторского стиля, но всё же не единственный, и, я надеюсь, не самый дорогой
автору ;)

Что касается жаргона, то ничего криминально-жаргонного я в Ваших текстах 
не встретил, и почти все термины у Вас, кстати, переведены. Кроме того,
некоторая специальность текста не противоречит идее книжки: она же адресована
разработчикам или будущим разработчикам, т. е. достаточно хорошо владеющим
жаргоном людям, иначе они бы даже не взялись становиться разработчиками.
Вот если бы речь шла о документации для пользователя, то никакая жаргонность
была бы неуместна, просто потому что текст в этом случае становится совершенно
непонятным пользователю, хоть и кажется совершенно ясным специалисту. 

Единственный вопрос вызвал термин "кляуза" -- я так и не понял, это "clause"? Если так, то русская 
транслитерация его была бы "клауза", а то получается странная путаница 
паронимов. С другой стороны, я эту кляузу встречал ещё где-то, и если так уже прочно принято, то лучше, конечно, не ломать традицию.

Не могу согласиться с Вашим огульным осуждением редактуры, как 
"иссушающей" текст. Обилие разговорных (личных) и жаргонных выражений нередко 
свидетельствует не о блестящем и лёгком авторском стиле, а наоборот, о 
недостаточном владении регистром письменной речи. Обычно такой текст 
ещё и малопонятен неподготовленному читателю. Желание редактора это
исправить вполне оправданно, а если стиль действительно есть, уверяю Вас, 
редактор не станет его искоренять. Но, понятно, что это идеальный редактор, 
которого в природе нет. А так, конечно, бывают и личные тараканы редактора, 
но есть случаи, которые очевидны большинству читателей, и не только 
редакторам. 

Приведу одно предложение из Вашего текста, которое мне бы хотелось перестроить:

> Определение зависимостей основано на нахождении в модулях конструкций с
> оператором import и использование его параметров для построения
> зависимостей.

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

> Насколько я готов включать результат такой правки в текст - я, честно говоря, не знаю.  Иногда меня удается убедить. 

А после этого описания задач правки? Впрочем, с Вашим текстом проблем
действительно почти нет, однако мне было важно продемонстрировать необходимость
правки в общем случае.

> > > 4. Python-полиси содержит явные и неявные ссылки на другую аналогичную документацию, в частности из пакета rpm/rpm-build. Будет ли
> > > эта документация поддерживаться там же (может быть, уже поддерживается)?
> > 
> Для этого их нужно позиционировать. Для этого нужно чбы было общедоступное место,
> в котором эта документация гарантировано есть. Иными словами, нужно чбы коллекция 
> полиси была замкнутой и мне не нужно было описывать "как поскипать (например) поиск зависимостей
> в каталоге /usr/share/doc", зная, что это описано в таком-то месте другой полиси. В текущей ситуации
> это боле-менее срабатывает для rpm (-build?) (там где Димина дока про макросы), в остальных случаях
> ситуация хуже. 

Вообще таким общедоступным местом должен стать alt-docs-devel. На него 
предлагаю и ориентироваться. Димины тексты там есть, если появится 
необходимость сослаться и на другие полиси, имеющие отношение к сборке пакетов,
если смысл заняться и их включением в alt-docs-devel (по крайней мере толкнуть
на эту тему авторов и меня).

> > А если в начале каждого полиси, опубликованного в alt-docs-devel, поставить обязательную краткую справку:
> > к какой версии соответствующего продукта этот  
> 
> Как бы еще обязать читателя ее прочитывать? Знаете, я работал над одной книжечкой старательно протестировал
> все примеры и выписал там же все номера версий использованноег софта и т.д. т.п. Через два года после издания
> посыпались жалобы читателей что книга "ужасна" так как "ни один" пример не работает. Объяснение очень простое:
> за два года сменились мажоры подавляющего большинства продуктов. А вспомнил я это как пример отношения
> читателей  к таким комментариям. Конечно, я всегда могу отмазаться, показав комментарий - но потребителю от этого
> не легче.

Но тогда проблема и с замечанием, что текст мог устареть -- пользователь 
точно так же может его проигнорировать и недоумевать потом. Лучше уж
предоставить побольше информации заинтересованным лицам.

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

> Я не случайно сказал про ветви. Так сложилось (и я считаю что это правильно  рад тому, что хотя бы в одном случае это удалось сложить),
> у нас почти всегда активны минимум две ветви полиси: в дедале и в сизифе. В дедале типа действщая модель в натуральную 
> величину.

Ну так это бы нужно и написать в начале полиси, логично? Я не нашёл, м. б. 
пропустил?

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

[devel] Re: ALT packaging docs

[Vitaly Ostanin]

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

Kirill Maslinsky пишет:

<skipped/>

>Все документы из пакетов alt-docs-* скоро таки будут опубликованы на сайте 
>docs.altlinux.ru, и там будут всегда последние версии. Сейчас последние 
>версии документов представлены в Сизифе в пакетах alt-docs-*.
>  
>

Если не секрет, в каком виде будут опубликованы документы, и как будет 
сделан сайт?

Сделанная в /beta версия в Website годится только как затычка.

В общем, IMHO, как стоит сделать docs.altlinux.ru:

Нужна навигация, в которую можно вставить документы в html, пусть и с 
правкой стилей;

Нужна возможность в (сделанном в каждой странице) подвале оставлять 
комментарии и поправки, которые будут фиксироваться в bugzilla;

Нужно сохранить каталог releases статическим, в нём сейчас выложены 
стили, и они используют такие пути:
http://docs.altlinux.ru/releases/xsl/current/

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: ALT packaging docs

[Kirill Maslinsky]

> <skipped/>
> 
> >Все документы из пакетов alt-docs-* скоро таки будут опубликованы на сайте 
> >docs.altlinux.ru, и там будут всегда последние версии. Сейчас последние 
> >версии документов представлены в Сизифе в пакетах alt-docs-*.
> > 
> >
> 
> Если не секрет, в каком виде будут опубликованы документы, и как будет 
> сделан сайт?

Пока секрет даже для меня, точнее говоря -- не знаю. :(
> 
> Сделанная в /beta версия в Website годится только как затычка.

Первоначально -- в виде затычки. Потому что текстов текущей документации 
online вообще нет, только в пакетах в Сизифе.

> В общем, IMHO, как стоит сделать docs.altlinux.ru:
> 
> Нужна навигация, в которую можно вставить документы в html, пусть и с 
> правкой стилей;

Не совсем понял. 

> Нужна возможность в (сделанном в каждой странице) подвале оставлять 
> комментарии и поправки, которые будут фиксироваться в bugzilla;

Отлично. Есть идеи, как это технически реализовать?

> Нужно сохранить каталог releases статическим, в нём сейчас выложены 
> стили, и они используют такие пути:
> http://docs.altlinux.ru/releases/xsl/current/

Пока я предполагал статически выложить все существующие пакеты с документацией,
сделав главную страницу наподобие alt-docs-main, только с добавочной ссылкой
на раздел "О проекте". 

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

[devel] Re: ALT packaging docs

[Vitaly Ostanin]

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

Kirill Maslinsky пишет:

>><skipped/>
>>
>>    
>>
>>>Все документы из пакетов alt-docs-* скоро таки будут опубликованы на сайте 
>>>docs.altlinux.ru, и там будут всегда последние версии. Сейчас последние 
>>>версии документов представлены в Сизифе в пакетах alt-docs-*.
>>>
>>>
>>>      
>>>
>>Если не секрет, в каком виде будут опубликованы документы, и как будет 
>>сделан сайт?
>>    
>>
>
>Пока секрет даже для меня, точнее говоря -- не знаю. :(
>  
>
>>Сделанная в /beta версия в Website годится только как затычка.
>>    
>>
>
>Первоначально -- в виде затычки. Потому что текстов текущей документации 
>online вообще нет, только в пакетах в Сизифе.
>  
>

Ok. Осторожнее, не сотрите при выкладывании статические каталоги на 
docs.altlinux.ru

>>В общем, IMHO, как стоит сделать docs.altlinux.ru:
>>
>>Нужна навигация, в которую можно вставить документы в html, пусть и с 
>>правкой стилей;
>>    
>>
>
>Не совсем понял. 
>  
>

Можно вставлять страницы в навигацию - когда существует движок формирует 
страницу из своей навигации и взятой статической страницы docbook/html.

Можно вставлять навигацию в страницы - правкой статических страниц 
docbook/html и добавлением туда навигации. Кривоватый способ, может 
потребовать пересборки docbook/html при изменении структуры сайта.

>>Нужна возможность в (сделанном в каждой странице) подвале оставлять 
>>комментарии и поправки, которые будут фиксироваться в bugzilla;
>>    
>>
>
>Отлично. Есть идеи, как это технически реализовать?
>  
>

Да, в этом же треде озвучивались.

>>Нужно сохранить каталог releases статическим, в нём сейчас выложены 
>>стили, и они используют такие пути:
>>http://docs.altlinux.ru/releases/xsl/current/
>>    
>>
>
>Пока я предполагал статически выложить все существующие пакеты с документацией,
>сделав главную страницу наподобие alt-docs-main, только с добавочной ссылкой
>на раздел "О проекте". 
>  
>

PS Вы отправили цитируемое письмо в docs@ дважды.

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Mikhail Zabaluev]

В Птн, 12/11/2004 в 12:16 +0300, Andrey Orlov пишет:
> Поймите меня правильно - дело вовсе не в спортивной 
> правоте, работа по поддержке пакетов дело сугубо добровольное и я действительно не имею возможности
> поддерживать доку в докбук. Я один раз попробовал - на документации к Zope - и в общем-то этого напряга не выдержал.
> В том числе и потому, что самый частый вопрос, который я видел у себя в почтовом ящике - чем эту "№;%" прочитать и нельзя ли
> ее у меня получить в виде текста.

Вообще-то DocBook предназначен для того, чтобы исходную документацию
(которую никто, кроме авторов, в виде DocBook читать не будет) можно
было преобразовать в текст, HTML, PostScript и вообще во все, для чего
существуют XSL-преобразования.
Если не хочется вдаваться в подробности, можно просто использовать пакет
xmlto.

[devel] Re: ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Michael Shigorin]

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

On Fri, Nov 12, 2004 at 03:10:52PM +0300, Mikhail Zabaluev wrote:
> Вообще-то DocBook предназначен для того, чтобы исходную
> документацию (которую никто, кроме авторов, в виде DocBook
> читать не будет) можно было преобразовать в текст, HTML,
> PostScript и вообще во все, для чего существуют
> XSL-преобразования.

Надеюсь, ни от кого не _требуется_ *писать* в Единственно Верном
Формате? (для которого, помимо довольно специфичных, удобных
средств для сколь-нибудь продуктивной работы попросту нет, а мне
(и не только мне) учить emacs+присадки для исключительно этой
задачи как-то неинтересно.  Даже если *выгонять* можно хоть сразу
в ogg.

Вопрос можно считать риторическим, поскольку Кирилл уже всё
сказал по сути, и это более похоже на официальную позицию
координатора проекта.

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

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

Re: [devel] ALT packaging docs (was: О сборке программ на GTK / GNOME)

[Andrey Orlov]

On Friday 12 November 2004 15:10, Mikhail Zabaluev wrote:
> > поддерживать доку в докбук. Я один раз попробовал - на документации к Zope - и в общем-то этого напряга не выдержал.
> было преобразовать в текст, HTML, PostScript и вообще во все, для чего
> существуют XSL-преобразования.

На деле все оказалось не так просто. Проблем было очень много и я не думаю, что ситуация изменилась коренным
образом сейчас.

-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] Re: О сборке программ на GTK / GNOME

[Kirill Maslinsky]

Вы, Kirill Maslinsky, мне писали:
> Добрый день!
> 
> > > > Я так понимаю, что это следует включить в alt-packaging?
> > >
> > > Угу.
> > В каком формате туда принимают? В docbook?
> В Мастере есть пакет alt-doc-devel: это немного переработанные 
Точнее в Сизифе, alt-docs-devel

Прошу прощения, утренний туман в голове...

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

[devel] xmms policy (was: О сборке программ на GTK / GNOME)

[Michael Shigorin]

On Thu, Nov 11, 2004 at 11:16:27AM +0300, Kirill Maslinsky wrote:
> Как, собственно, и описание всех гласно и негласно существующих
> в Сизифе policy.

Ура.

XMMS Packaging Policy живёт в
/usr/share/doc/xmms-1.2.10/README.ALT-koi8r (вроде как
README.ALT* на сейчас de facto описывают особенности сборки --
стоит ли заводить иные названия для policy, если это именно оно?)

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

Re: [devel] xmms policy (was: О сборке программ на GTK / GNOME)

[Kirill Maslinsky]

Приветствую!

> XMMS Packaging Policy живёт в
> /usr/share/doc/xmms-1.2.10/README.ALT-koi8r (вроде как
> README.ALT* на сейчас de facto описывают особенности сборки --
> стоит ли заводить иные названия для policy, если это именно оно?)

Речь шла не о смене названий, а о включении таких текстов в единую книжку
про Sisyphus (alt-docs-devel). Потому что такие policy непосредственно
относятся к тематике этой книжки, нужны новым участникам, присоединяющимся к
проекту и при этом узнать о них можно только лично от разработчиков или
случайно. Я не помню упоминаний xmms packaging policy, что довольно
показательно.

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

[devel] Re: xmms policy (was: О сборке программ на GTK / GNOME)

[Michael Shigorin]

On Fri, Nov 12, 2004 at 01:58:54PM +0300, Kirill Maslinsky wrote:
> Я не помню упоминаний xmms packaging policy, что довольно
> показательно.

Первая ссылка по поиску этих слов на search.altlinux.ru -- драфт
пресловутой полиси с указанием постоянного места жительства
(README.ALT):

http://lists.altlinux.ru/pipermail/sisyphus/2004-January/033086.html

Может, такие анонсы стоит как-то дублировать в devel@ и/или
docs@?  Мне-то нетрудно, благо подписан на все эти рассылки, но в
общем случае сейчас существуют проблемы.

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

[devel] Re: О сборке программ на GTK / GNOME

[Vitaly Ostanin]

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

Kirill Maslinsky пишет:

>Добрый день!
>
>  
>
>>>>Я так понимаю, что это следует включить в alt-packaging?
>>>>        
>>>>
>>>Угу.
>>>      
>>>
>>В каком формате туда принимают? В docbook?
>>    
>>

Если нет больше желающих, могу перевести этот текст в docbook.

>В Мастере есть пакет alt-doc-devel: это немного переработанные 
>и дополненные ALT Packaging HOWTO и ALT Mantainer HOWTO -- из них 
>получилась небольшая кнжика, которая сейчас называется 
>"ALT Linux Team и проект Sysiphus". Было бы идеально, если текст 
>про упаковку GNOME-приложений вписался бы туда как раздел. 
>
>Принимаем в любом формате, предпочитаем plain text, не предпочитаем 
>OpenOffice. 
>  
>

Из OpenOffice не получить plain text ?

На самом деле сторонники OOo утверждают, что для OOo есть XSL-стили, 
позволяющие сохранять документы OOo в docbook.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: О сборке программ на GTK / GNOME

[Vitaly Lipatov]

On Thursday 11 November 2004 12:28, Vitaly Ostanin wrote:
> >>В каком формате туда принимают? В docbook?
>
> Если нет больше желающих, могу перевести этот текст в docbook.
Мы поговорим об этом позже, текст ещё немного не доделан. 
Впрочем, если срочно, то готов завтра выслать то что есть.


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] Re: О сборке программ на GTK / GNOME

[Kirill Maslinsky]

Привет!

> > >>В каком формате туда принимают? В docbook?
> >
> > Если нет больше желающих, могу перевести этот текст в docbook.
> Мы поговорим об этом позже, текст ещё немного не доделан. 
> Впрочем, если срочно, то готов завтра выслать то что есть.

Не срочно. Пусть лучше будет хороший полный текст. :)

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

Re: [devel] Re: О сборке программ на GTK / GNOME

[Kirill Maslinsky]

Добрый день!

> >Принимаем в любом формате, предпочитаем plain text, не предпочитаем 
> >OpenOffice. 
> > 
> >
> 
> Из OpenOffice не получить plain text ?

Практика показывает, что документ, написанный автором как plain text, обычно
более чётко _логически_ размечен, чем полученный конвертацией в plain text из
OOo. Проблема не в пользователях OOo, конечно, а в модели работы с документом,
WYSIWYG всё-таки. В результате делать грамотный, аккуратный и логически
размеченный документ в DocBook из такого текста немного дольше и муторнее, чем
если бы он сразу был написан в plain text. Возможно, дело в моих личных 
тараканах, но речь ведь и шла о предпочтениях :)

> На самом деле сторонники OOo утверждают, что для OOo есть XSL-стили, 
> позволяющие сохранять документы OOo в docbook.

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

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

Re: [devel] Re: О сборке программ на GTK / GNOME

[Mikhail Zabaluev]

В Птн, 12/11/2004 в 14:14 +0300, Kirill Maslinsky пишет:
> > На самом деле сторонники OOo утверждают, что для OOo есть XSL-стили, 
> > позволяющие сохранять документы OOo в docbook.
> 
> Ну да, есть. Только проблема не в том, чтобы получить DocBook, а в том, чтобы
> получить DocBook, из которого будут получаться адекватные конечные форматы. 
> Переделывать разметку DocBook, приводя её в соответствие с остальным массивом 
> документации, не проще, чем делать её с нуля.

Да, действительно, проблема в том, чтобы выразить средствами DocBook
семантическое предназначение тех или иных фрагментов текста.
Я сомневаюсь, что в OOo для этого есть адекватные стили: этот софт
все-таки находится ниже на пути от контента к представлению.

Re: [devel] Re: О сборке программ на GTK / GNOME

[Kirill Maslinsky]

> > Ну да, есть. Только проблема не в том, чтобы получить DocBook, а в том, чтобы
> > получить DocBook, из которого будут получаться адекватные конечные форматы. 
> > Переделывать разметку DocBook, приводя её в соответствие с остальным массивом 
> > документации, не проще, чем делать её с нуля.
> 
> Да, действительно, проблема в том, чтобы выразить средствами DocBook
> семантическое предназначение тех или иных фрагментов текста.
> Я сомневаюсь, что в OOo для этого есть адекватные стили: этот софт
> все-таки находится ниже на пути от контента к представлению.

Знаете, на мой взгляд DocBook тоже не находится на абслоютной высоте 
семантичности разметки. <emphasis role="bold"> и <bridgehead> -- примеры 
явного смешения логического и полиграфического представления данных. 
Да и вообще неправильно ранжировать разные инструменты по степени 
семантичности получающейся разметки. Она зависит только от автора, 
никакой стиль не может заставить его не смешивать логические категории.

-- 
Kirill Maslinsky
ALT Linux Team * Documentation Project   

Re: [devel] Re: О сборке программ на GTK / GNOME

[Anatoly A. Yakushin]

Vitaly Ostanin пишет:

<skip>
> Из OpenOffice не получить plain text ?
> 
> На самом деле сторонники OOo утверждают, что для OOo есть XSL-стили, 
> позволяющие сохранять документы OOo в docbook.
> 
> <skipped/>

Эти стили входят в штатную поставку ООо. Равно как и шаблон 
для разметки. Работает, проверено.

Из недостатков - очень мало тегов поддерживается.
Из достоинств - очень легко добавлять новые теги.

P.S. Работает ли это в Альтовской сборке ООо - не знаю.

.DOC

[devel] Re: О сборке программ на GTK / GNOME

[Vitaly Ostanin]

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

Anatoly A. Yakushin пишет:

> Vitaly Ostanin пишет:
>
> <skip>
>
>> Из OpenOffice не получить plain text ?
>>
>> На самом деле сторонники OOo утверждают, что для OOo есть XSL-стили, 
>> позволяющие сохранять документы OOo в docbook.
>>
>> <skipped/>
>
>
> Эти стили входят в штатную поставку ООо. Равно как и шаблон для 
> разметки. Работает, проверено.


Как они называются, куда нужно ткнуть, чтобы попробовать?

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: О сборке программ на GTK / GNOME

[Andrey Orlov]

On Thursday 11 November 2004 11:16, Kirill Maslinsky wrote:
> Кстати, к Андрею Орлову: тексты про упаковку модулей Питона и программ
> на Питоне (очень толковые и нужные) были бы в этой же книжке как нельзя
> более кстати. Как, собственно, и описание всех гласно и негласно 
> существующих в Сизифе policy.

Я уже не раз писал, если кто-то возьмется поддерживать их именно в рамках 
alt-packaging, то я окажу ему всю возможную помощь со своей стороны. Лично
я не в состоянии ни поддерживать два экземпляра док, ни вести все доки в докбуке:
Компания, на деньги которой я нахожу свободное время на поддерржку питоновских
пакетов в альтлитнуксе, отрицает возможность использования докбук в качестве документации,
аргументируя это тем, что для Python-World стандартом де факто является ST & reST, под работу
с ними существует масса инструментов именно для python/zope, в т.ч. Wiki и т.п., ну  и так далее.

Я еще раз подчеркиваю, что всячески приветствую это начинание и готов окказать всю необходимую
помощь тому, кто возьмет на себе поддержку текста в docbook.


-- 
WthBstRgrds -- Андрей Орлов --  
 --- http: www.neural.ru, mail: cray@neural.ru, jid: cray@altlinux.org ---
----------------------------------------

Re: [devel] О сборке программ на GTK / GNOME

[Alexey I. Froloff]

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

* Vitaly Lipatov <lav@> [041110 02:23]:
> По результатам переписки разработчиков ALT Linux Team
> составлены советы по упаковке программ GTK, GNOME и KDE.
Виталий, громадная просьба - посмотрите пожалуйста на пакет
xscreensaver-gnome, всё ли там правильно?  Может я каких лишних
файлов туда положил или забыл что-то нужное?

Ещё вопрос - для чего нужны %_datadir/applications/* и как их
правильно упаковывать?

-- 
Regards, Sir Raorn.
-------------------
Как оно было:
Я сделал libpng2 и libpng3, собрал imlib с libpng3, после чего весь гном
накрылся.
		-- ldv in devel@

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

Re: [devel] О сборке программ на GTK / GNOME

[Vitaly Lipatov]

On Wednesday 10 November 2004 07:58, Alexey I. Froloff wrote:
>
> Ещё вопрос - для чего нужны %_datadir/applications/* и как их
В файлах .desktop кроме названия программы, способа её запуска и
комментария, обычно также указаны сведения о том, какие
форматы способна обрабатывать та или иная программа.

> правильно упаковывать?
Так и паковать, как указано в разделах
Файлы меню
Обновление базы данных по меню (сейчас я его переименовал в
Обновление базы обрабатываемых форматов)


-- 
Lav
Виталий Липатов
Санкт-Петербург
GNU! ALT Linux Team! LaTeX! LyX!

Re: [devel] О сборке программ на GTK / GNOME

[Alexey I. Froloff]

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

* Vitaly Lipatov <lav@> [041110 11:41]:
> > правильно упаковывать?
> Так и паковать, как указано в разделах
> Файлы меню
> Обновление базы данных по меню (сейчас я его переименовал в
> Обновление базы обрабатываемых форматов)
Пардон, проглядел этот момент.

И опять же на примере xscreensaver-gnome - там есть файл
%_datadir/control-center-2.0/capplets/screensaver-properties.desktop
Оно должно лежать в пакете или какой-то из menu-methods генерит
это автоматически?

Вообще, что у нас первично в GNOME, *.desktop или menu?  Кто из
кого должен генериться?

P.S. Хорошо бы подобное описание для KDE... Zerg, ау!

-- 
Regards, Sir Raorn.
-------------------
> Похоже, обновление rpm не проходит.
Похоже, что у вас apt слишком старый, раз он rpm запускает.
Похоже, что у вас /bin/rpm статически собранный, раз он падает.
Похоже, что у вас rpm слишком старый, поскольку /bin/rpm собран
статически.

Вывод: похоже, что вам не стоит обновлять такую систему без промежуточного
репозитария.
		-- ldv in sisyphus@

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

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 12:06 Alexey I. Froloff 
написал(a):
> * Vitaly Lipatov <lav@> [041110 11:41]:
> > > правильно упаковывать?
> >
> > Так и паковать, как указано в разделах
> > Файлы меню
> > Обновление базы данных по меню (сейчас я его переименовал в
> > Обновление базы обрабатываемых форматов)
>
> Пардон, проглядел этот момент.
>
> И опять же на примере xscreensaver-gnome - там есть файл
> %_datadir/control-center-2.0/capplets/screensaver-properties.desk
>top Оно должно лежать в пакете или какой-то из menu-methods
> генерит это автоматически?
Судя по-тому, что у меня есть в этом каталоге 2 файла, пренадлежащие 
пакетам, они статичные.

> Вообще, что у нас первично в GNOME, *.desktop или menu?
Это 2 параллельные вещи. Хорошо, чтоб были обе.
%_menudir обязательно, а %_datadir/applications/*.desktop пока 
опционально.
Когда-нибудь в далеком будущем бОльшая часть оконных менеджеров 
будет уметь нативно читать %_datadir/applications. Тогда пакет menu 
будет не нужен.

> Кто из 
> кого должен генериться?
Есть статичный, нативный вариант - %_datadir/applications, а есть 
генерируемый из menu-файлов - %_datadir/application-alt

> P.S. Хорошо бы подобное описание для KDE... Zerg, ау!
ftp://ftp.altlinux.org/pub/people/zerg/menu
KDE не особо при чем, %_datadir/applications и %_menudir - это общее 
для всех.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Alexey I. Froloff]

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

* Sergey V Turchin <zerg@> [041110 12:32]:
> > P.S. Хорошо бы подобное описание для KDE... Zerg, ау!
> ftp://ftp.altlinux.org/pub/people/zerg/menu
> KDE не особо при чем, %_datadir/applications и %_menudir - это общее 
> для всех.
А %_datadir/applink/ ?  Пакет ethereal-kde непример...

-- 
Regards, Sir Raorn.
-------------------
По "техническим причинам" я буду молчать или реагировать с бооольшой
задержкой на все почтовое в лучшем случае до понедельника следующей недели.
		-- ldv in devel@

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

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 12:39 Alexey I. Froloff 
написал(a):
> * Sergey V Turchin <zerg@> [041110 12:32]:
> > > P.S. Хорошо бы подобное описание для KDE... Zerg, ау!
> >
> > ftp://ftp.altlinux.org/pub/people/zerg/menu
> > KDE не особо при чем, %_datadir/applications и %_menudir - это
> > общее для всех.
>
> А %_datadir/applink/ ?  Пакет ethereal-kde непример...
Это старый, KDE-шный вариант %_datadir/applications
Они просто не перенесли пока.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 12:39 Alexey I. Froloff 
написал(a):
> * Sergey V Turchin <zerg@> [041110 12:32]:
> > > P.S. Хорошо бы подобное описание для KDE... Zerg, ау!
> >
> > ftp://ftp.altlinux.org/pub/people/zerg/menu
> > KDE не особо при чем, %_datadir/applications и %_menudir - это
> > общее для всех.
>
> А %_datadir/applink/ ?  Пакет ethereal-kde непример...
Запаковывайте так как они лежат, там наверняка пока нет необходимой 
информации для перемещения в %_datadir/applications

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Alexey I. Froloff]

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

* Sergey V Turchin <zerg@> [041110 12:48]:
> > А %_datadir/applink/ ?  Пакет ethereal-kde непример...
> Запаковывайте так как они лежат, там наверняка пока нет необходимой 
> информации для перемещения в %_datadir/applications
Конкретно в ethereal эти файлы лежат отдельным архивом.  Есть
мнение, что генерились они вручную.

В любом случае принимаю все комментарии по поводу упаковки
KDE/GNOME-специфичных файлов по адресу bugzilla.altlinux.org

-- 
Regards, Sir Raorn.
-------------------
Вообще кто вам сказал, что Unix - это дружественно для пользователя? И 
зачем его таким нужно делать?
		-- rider in devel@

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

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 12:50 Alexey I. Froloff 
написал(a):
> * Sergey V Turchin <zerg@> [041110 12:48]:
> > > А %_datadir/applink/ ?  Пакет ethereal-kde непример...
> >
> > Запаковывайте так как они лежат, там наверняка пока нет
> > необходимой информации для перемещения в %_datadir/applications
>
> Конкретно в ethereal эти файлы лежат отдельным архивом.  Есть
> мнение, что генерились они вручную.
Конечно же вручную. Автоматом туда толко переводы могут 
запихиваться. В CVS KDE, например.

> В любом случае принимаю все комментарии по поводу упаковки
> KDE/GNOME-специфичных файлов по адресу bugzilla.altlinux.org
А 
ftp://ftp.altlinux.org/pub/people/zerg/menu/menu-packaging-howto-current.txt
не подходит?

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Alexey I. Froloff]

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

* Sergey V Turchin <zerg@> [041110 13:22]:
> > В любом случае принимаю все комментарии по поводу упаковки
> > KDE/GNOME-специфичных файлов по адресу bugzilla.altlinux.org
> А 
> ftp://ftp.altlinux.org/pub/people/zerg/menu/menu-packaging-howto-current.txt
> не подходит?
Не очень.  Там нет про applink и control-center-2.0 например.
Может в этих оболочка ещё что-то есть, о чём я просто не знаю...

-- 
Regards, Sir Raorn.
-------------------
Не волнуйтесь, glibc из 2-й Fedorы с этой Borlandовской поделкой работать
будет точно также, как и glibc из Сизифа.
		-- ldv in sisyphus@

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

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 13:27 Alexey I. Froloff 
написал(a):
> * Sergey V Turchin <zerg@> [041110 13:22]:
> > > В любом случае принимаю все комментарии по поводу упаковки
> > > KDE/GNOME-специфичных файлов по адресу bugzilla.altlinux.org
> >
> > А
> > ftp://ftp.altlinux.org/pub/people/zerg/menu/menu-packaging-howt
> >o-current.txt не подходит?
>
> Не очень.  Там нет про applink и control-center-2.0
Это оба частных варианта. На первый можно уже забивать, о втором я 
вообще понятия не имею.
Подозреваю, что это аналог KControl, в котором все пункты сделаны 
теми же 2-мя вариантами меню, но никто этим не занимается.

> например. 
> Может в этих оболочка ещё что-то есть, о чём я просто не знаю...

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Mikhail Zabaluev]

В Срд, 10/11/2004 в 13:38 +0300, Sergey V Turchin пишет:
> В сообщении от Среда 10 Ноябрь 2004 13:27 Alexey I. Froloff 
> написал(a):
> > * Sergey V Turchin <zerg@> [041110 13:22]:
> > > > В любом случае принимаю все комментарии по поводу упаковки
> > > > KDE/GNOME-специфичных файлов по адресу bugzilla.altlinux.org
> > >
> > > А
> > > ftp://ftp.altlinux.org/pub/people/zerg/menu/menu-packaging-howt
> > >o-current.txt не подходит?
> >
> > Не очень.  Там нет про applink и control-center-2.0
> Это оба частных варианта. На первый можно уже забивать, о втором я 
> вообще понятия не имею.

Это апплеты для GNOME Control center. В меню их вряд ли стоит
экспортировать, т.к. там уже есть пункт на весь control-center.

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 13:55 Mikhail Zabaluev 
написал(a):

[...]

> > втором я вообще понятия не имею.
>
> Это апплеты для GNOME Control center. В меню их вряд ли стоит
> экспортировать, т.к. там уже есть пункт на весь control-center.
Если этого можно не делать, то лучше не делать. Проще жить будет.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Yuri N. Sedunov]

On Среда 10 Ноябрь 2004 11:40, Vitaly Lipatov wrote:
> On Wednesday 10 November 2004 07:58, Alexey I. Froloff wrote:
> > Ещё вопрос - для чего нужны %_datadir/applications/* и как их
>
> В файлах .desktop кроме названия программы, способа её запуска и
> комментария, обычно также указаны сведения о том, какие
> форматы способна обрабатывать та или иная программа.

Давайте дадим ссылки на первоисточники. 
http://www.freedesktop.org/Standards/desktop-entry-spec


> > правильно упаковывать?
>
> Так и паковать, как указано в разделах
> Файлы меню
> Обновление базы данных по меню (сейчас я его переименовал в
> Обновление базы обрабатываемых форматов)

http://www.freedesktop.org/Software/desktop-file-utils


-- 
Yuri N. Sedunov
11/10/04 18:58:55

Re: [devel] О сборке программ на GTK / GNOME

[Sergey V Turchin]

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

В сообщении от Среда 10 Ноябрь 2004 02:22 Vitaly Lipatov написал(a):

[...]

> 2. Файлы из каталога
> %_datadir/mime-info/*
> не используется GNOME-программами, которые получают
> mime-информацию из пакета shared-mime-info.
>
> Тем не менее эти файлы используются рядом программ (например
> KDE),
> так что их тоже надо паковать.
При этом пакет не получает никаких дополнительных зависимостей.

[...]

> Поиск файлов локализации - %find_lang
> ====================================
>
> %find_lang вызывается в секции %install
>
> Для программ GNOME указывается:
> %find_lang --with-gnome %name
>
> При этом find-lang кроме файлов переводов в %_datadir/locale ищет
> файлы
> справки Гном в %_datadir/gnome/help и .omf файлы в %_datadir/omf
>
> Поэтому не нужно указывать в секции %files каталоги с locale, а
> также
> %_datadir/omf/%name
> %_datadir/gnome/help/
>
>
> Для программ KDE указывается:
> %find_lang --with-kde %name
>
> При этом find-lang ищет файлы справки KDE в %_docdir/HTML
>
> Далее секция %files оформляется следующим образом:
> %files -f %name.lang
К тому же %find_lang, являющийся скриптом, имеет и другие параметры,
делающие его более гибким.

>
> Файлы меню
> ===========
Весь этот раздел IMHO лучше переместить в 
ftp://ftp.altlinux.org/pub/people/zerg/menu/menu-packaging-howto-current.txt

> Файл меню либо создаётся непосредственно заданием
> его содержимого, либо формируется.
> Как правило программа содержит файл .desktop,
> из него можно получить файл меню следующей командой
> в разделе %install:
>
> freedesktop2menu.pl %name "Путь разделов меню" \
>     %buildroot%_datadir/applications/%name.desktop \
>     %buildroot%_menudir/%name
>
> При использовании этого скрипта в пакете
> должна быть указана зависимость:
> BuildPreReq: menu-devel
>
> Каталог для файлов меню обычно создают командой:
> %__mkdir_p %buildroot%_menudir
>
> Созданный файл меню устанавливается в каталог %_menudir.
> При установке или удалении пакета меню должно переформироваться,
> для этого в спеке должны быть секции:
>
> %post
> %update_menus
>
> %postun
> %clean_menus
>
> В секции %files:
>
> %_menudir/*
> %_datadir/applications/*
Пережиток KDE-шного прошлого
%_datadir/applnk
тоже надо. Не появляется дополнительных зависимостей.
> и возможно
> %_datadir/application-registry/*

> Обновление базы данных по меню
> ==============================
И этот тоже.

> В файлах desktop обычно хранится информация о том, какие
> форматы способна обрабатывать та или иная программа.
Не совсем. Это лишь один из параметров.

> это нужно только в случае если в %_datadir/applications/*.desktop
> есть
> $ grep -i mime //usr/share/applications/*.desktop
> MimeType=application/postscript;
>
> В спеке должны быть секции:
> %post
> %update_desktopdb
>
> %postun
> %clean_desktopdb
>
> В пакете должна быть указана зависимость:
> Requires(post,postun): desktop-file-utils
> BuildPreReq: desktop-file-utils
>
> Используется вне зависимости от типа программы в пакете,
> и всегда должно быть указано.

[...]

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] О сборке программ на GTK / GNOME

[Yuri N. Sedunov]

On Среда 10 Ноябрь 2004 02:22, Vitaly Lipatov wrote:

> Файлы информации о mime-типах
> =============================
>
> В этих файлах хранится описание форматов файлов
> (их mime-type, комментарием, способом определения принадлежности
> к
> формату по MAGIC value и шаблону...)

http://www.freedesktop.org/Standards/shared-mime-info-spec
http://www.freedesktop.org/Software/shared-mime-info

> 1. Если в пакете есть файлы /usr/share/mime/packages/*.xml,
> то при его установке, удалении, обновлении необходимо
> обновить и кеш базы mime-типов с использованием в spec-файле
> макросов
> %update_mimedb и %clean_mimedb.
>
> То есть в спеке должны быть секции:
> %post
> %update_mimedb
>
> %postun
> %clean_mimedb
>
> И указаны зависимости:
> Requires(post,postun): shared-mime-info >= 0.15-alt2


-- 
Yuri N. Sedunov
11/10/04 19:10:39