[devel] Re: Q: specspo?

[Вячеслав]

В Пнд, 14/03/2005 в 00:32 +0300, Dmitry V. Levin пишет:
> On Sun, Mar 13, 2005 at 11:22:23PM +0300, Вячеслав Диконов wrote:
> > В Вск, 13/03/2005 в 11:05 +0300, Alexey I. Froloff пишет:
> > > * Вячеслав Диконов <sdiconov@> [050312 12:23]:
> > > > > > Пусть в базе лежат и вынимаются по имени пакета, которое всегда
> > > > > > уникально.
> > > > > Базы в системе может и не быть (у меня - не будет).
> > > > Я не имел ввиду настоящие базы данных, SQL и иже с ним. PO файл -
> > > > таблица, а таблица - уже (или почти уже) простейшая база.
> > > Я понял.  Мне они не нужны ни в системе ни при сборке пакета.
> > Ну так и не ставьте. Имена (glibc.x-x-x.src.rpm и т.п.) сами за себя
> > говорят.
> > 
> > Я категорически против оставления в spec английских описаний так как это
> > будет мешать централизованно хранить и редактировать описания для всех
> > языков. Также не следует давать приемущества какому-либо конкретному
> > языку. 
> 
> Вы не поверите, но specspo является именно такой базой данных, о которой
> было сказано где-то в начале этого треда.
> А именно, сначала по ключу типа "rpm(Summary)" ищется фраза, например,
> "The RPM package management system", а потом для этой фразы ищется перевод
> для языка из текущей локали, например, "Менеджер пакетов RPM".
Зря. Есть несколько фактов:
1) в пределах репозитория имена пакетов всегда уникальны (за этим следит
apt). Это значит, что имени достаточно в качестве ключа.
2) описания не 100% статичны. Они могут меняться, и тогда описанный вами
механизм нахождения переводов будет сбоить. Пример - пакеты вроде
exult-utils, которые в описании содержат список входящих в них утилит.
Этот список (и соответственно поле Description) меняется от версии к
версии.
3) полное разделение кода и ресурсов в spec позволит проще и удобнее
манипулировать описаниями, исправлять опечатки и т.п. независимо от
цикла пересборки самого пакета. Хранение _всех_ языков в одном месте
позволит использовать системы памяти переводов, работающие с мелкими
сегментами, и автоматически синхронизировать переводы с оригиналом. 

У меня есть пакеты, оригинал описания которых написан на французском.
Английский - один из переводов.

> При этом, если описание найдено в specspo, то описание из пакета не
> используется.  Это, кстати, неоднократно служило причиной воплей типа
> "я же поменял описание пакета, так почему же оно осталось прежним?"
> 
> И всё же описание в пакете стоит оставить хотя бы на английском, на тот
> случай, если specspo не используется. :)
Если описания хранятся в базе, а некто Х не хочет их читать - имеет
право не читать и не ставить базу. Поскольку для кажого языка - свой .po
файл, то можно оставить только файл лишь для одного из языков.

> > И еще можно историю изменений тоже сделать переводимой и хранить вне
> > spec. После такого шага spec станут очень компактными и будут содержать
> > только инструкции по сборке и упаковке. Все метаданные (описания,
> > история, любые виды рейтингов, ссылки на баги) могут быть доступны в
> > специальном хранилище и иметь безупречный механизм i18n.
> 
> Разработчику (мне, например), было бы неудобно работать с changelog'ом вне
> spec-файла.
Это легко автоматизировать. Можно писать традиционный spec и разделять
его в момент сборки для репозитория, помещая в srpm только скрипт, а
метаданные - в базу. Базой могут заниматься уже другие люди. Сборщику
остаётся только следить за кодом сборки/исправлениями/версиями, что, как
говорит мой опыт, облегчает жизнь. 

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

-- 
Вячеслав Диконов <sdiconov на mail.ru>