[docs] Re: rpm-публикации (Was: deleting alt-entities)

Vitaly Ostanin vyt на vzljot.ru
Ср Фев 11 15:16:23 MSK 2004


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-ссылок минимальна, ссылок между
книгами вообще нет. К тому же базу ссылок можно собирать
отдельным пакетом, и отслеживать ситуации, когда прямую ссылку
сделать нельзя. Только можно давать ссылку просто на название
книги.

> > и возможностей обновления. Очевидно, что FAQ будет
> > обновляться чаще, чем install.
> 
>   Допустим, что так. И что?

Значит, придётся пересобирать. В случае отдельных книг придётся
пересобирать и качать только нужную.

Насколько я понимаю, избавление от "монстроидальности" пакетов в
пользу модульности - один из принципов в Sisyphus. Поправьте
меня, pls, если я не прав.

> > >   Достоинство метода состоит в том, что не надо задумывать
> > >   о зависимостях,
> > > о версиях пакетов a la alt-entities, и главное --
> > > реализуется он прямолинейно и очевидно.
> > 
> > Зависимости на версии я пропишу, тогда тоже не надо будет
> > задумываться.
> > 
> > > > Тогда cvs будет недоступен. Кроме того,
> > > > использование самых свежих данных cvs далеко не всегда
> > > > оправдано.
> > > 
> > > $ cp -r $docs_root $my_docs_root
> > > $ cd $my_docs_root
> > > $ cvs update -r <recommended_revision>
> > > $ ... работа в $my_docs_root ...
> > 
> > Из этого понятно, что можно работать со своей копией/версиями
> > из cvs. Я не об этом, а о том, что сборка будет (и должна)
> > проходить без cvs.
> 
>   Зачем такое желание? Те, кому зачем-то нужно часто
>   пересобирать
> документацию, те имеют cvs. В какие-то определённые моменты
> времени можно делать "снимок" содержимого cvs в виде src.rpm,
> позволяя делать пересборку документации из "рекомендованной"
> версии cvs.

cvs - это средство разработки. Релиз должен собираться без cvs.

> > > .... <skip про каталоги /> ....
> > 
> > С каким вердиктом <skip/> ? :)
> 
>   С таким, что вначале надо убедить в простом подходе к
>   "rpm-публикациям"
> и только потом, не распыляя сил, переходить к entities.

Необходимость убеждать несколько тормозит :(

<skipped/>

-- 
Regards, Vyt
mailto:  vyt на vzljot.ru
JID:     vyt на vzljot.ru
----------- следущая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: отсутствует
Url     : /pipermail/docs/attachments/20040211/f0c1d47e/attachment.bin


Подробная информация о списке рассылки docs