[docs] Re: rpm-публикации (Was: deleting alt-entities)
Oleg A. Paraschenko
olpa на xmlhack.ru
Чт Фев 12 23:29:59 MSK 2004
Привет!
On Wed, 11 Feb 2004 15:16:23 +0300
Vitaly Ostanin <vyt на vzljot.ru> wrote:
> On Sun, 1 Feb 2004 20:10:41 +0300
> "Oleg A. Paraschenko" <olpa на xmlhack.ru> wrote:
>
> > Привет!
> >
> > On Sun, 1 Feb 2004 19:22:28 +0300
> > Vitaly Ostanin <vyt на vzljot.ru> wrote:
> >
> > ...
> > > >
> > > > * по "make srcrpm" куда-то выкладывается срез cvs ("cvs
> > > > checkout" на
> > > > весь $docs_root, может быть с некоторыми исключениями), а
> > > > также файлы, необходимые для создания rpm-пакетов;
> > >
> > > rpm обычно делается из tarball-архивов. Делать один
> > > гигантский tarball со всем срезом cvs нет смысла.
> > >
> > > > * из этого всего собирается .src.rpm;
> > > >
> > > > * .src.rpm имеет такое свойство, что из него получается
> > > > много маленьких
> > > > итоговых rpm, содержащих нужную документацию.
> > >
> > > В Сизифе принято дробить пакеты для достижения более гибких
> > > зависимостей
> >
> > Это великолепно когда есть возможность дробить. Но у нас не
> > сравнительно
> > независимые пакеты ПО, но модульная документация, которая
> > потенциально содержит перекрёстные связи. Нельзя вытащить
> > просто FAQ или install, надо также положить базу olink-ссылок,
> > всё что берётся по xinclude и ещё что-нибудь. Наверное, можно
> > придумать подход в котором всё будет работать, но на реализацию
> > уйдёт очень много усилий.
>
> Всё не так сложно. База olink-ссылок минимальна, ссылок между
> книгами вообще нет. К тому же базу ссылок можно собирать
> отдельным пакетом, и отслеживать ситуации, когда прямую ссылку
> сделать нельзя. Только можно давать ссылку просто на название
> книги.
Так или иначе, надо писать rpm spec. Вычитаем это из общего объёма
работ. Остаётся:
checkout от cvs: ничего
независимые пакеты: 1) ... 2) ... 3) ... etc, причём реализация некоторых
из этих k) не особо очевидна
Неудивительно, что монолитный вариант мне нравится больше.
>
> > > и возможностей обновления. Очевидно, что FAQ будет
> > > обновляться чаще, чем install.
> >
> > Допустим, что так. И что?
>
> Значит, придётся пересобирать. В случае отдельных книг придётся
> пересобирать и качать только нужную.
Ну и что? Те, кому может потребоваться пересобирать книгу, те имеют cvs.
Остальные вряд ли будут заниматься обновлением документации (особенно,
учитывая, что документацию всё равно никто не читает).
Выгода от создания фичи = выгода от однократного использования фичи *
частота использования фичи. В данном случае, боюсь, это близко к нулю.
Кстати, не совсем в тему, но предлагаю также посмотреть:
Hard-assed Bug Fixin'
http://joelonsoftware.com/articles/fog0000000014.html
As a software developer, fixing bugs is a good thing. Right? Isn't it
always a good thing? No! Fixing bugs is only important when the value
of having the bug fixed exceeds the cost of the fixing it.
>
> Насколько я понимаю, избавление от "монстроидальности" пакетов в
> пользу модульности - один из принципов в Sisyphus. Поправьте
> меня, pls, если я не прав.
У меня есть такое мнение, что docs -- это не Sisyphus. И то, что они
сейчас объединены -- это историческое наследие.
...
> >
> > Зачем такое желание? Те, кому зачем-то нужно часто
> > пересобирать
> > документацию, те имеют cvs. В какие-то определённые моменты
> > времени можно делать "снимок" содержимого cvs в виде src.rpm,
> > позволяя делать пересборку документации из "рекомендованной"
> > версии cvs.
>
> cvs - это средство разработки. Релиз должен собираться без cvs.
Не cvs, но снимок из cvs. Просто набор файлов.
>
> > > > .... <skip про каталоги /> ....
> > >
> > > С каким вердиктом <skip/> ? :)
> >
> > С таким, что вначале надо убедить в простом подходе к
> > "rpm-публикациям"
> > и только потом, не распыляя сил, переходить к entities.
>
> Необходимость убеждать несколько тормозит :(
Ну да.
>
> <skipped/>
>
> --
> Regards, Vyt
> mailto: vyt на vzljot.ru
> JID: vyt на vzljot.ru
--
Oleg
Подробная информация о списке рассылки docs