[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