[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