From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ivan Zakharyaschev To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-r Content-Transfer-Encoding: 8BIT Subject: [devel] RPM: including additional docs Sender: devel-admin@linux.iplabs.ru Errors-To: devel-admin@linux.iplabs.ru X-BeenThere: devel@linux.iplabs.ru X-Mailman-Version: 2.0beta6 Precedence: bulk Reply-To: devel@linux.iplabs.ru List-Help: List-Post: List-Subscribe: , List-Id: IPLabs Linux Team Developers mailing list List-Unsubscribe: , List-Archive: http://www.logic.ru/pipermail/devel/ X-Original-Date: Thu, 23 Nov 2000 21:46:07 +0300 (MSK) Date: Thu, 23 Nov 2000 21:46:07 +0300 (MSK) Archived-At: List-Archive: List-Post: Добрый вечер! Пользуясь RPM для сборки пакетов, столкнулся с некоторыми проблемами. После обдумывания и попыток найти решения, мне пришло в голову несколько мыслей по поводу возможных усовершенствований RPM. Думаю, что нет смысла их не высказать. Проблема: в пакет включается дополнительная документация, которая берется из отдельных файлов (они указаны как SourceX). Эти файлы могут представлять из себя как архивы, так и просто файлы, включаемые в пакет почти без изменений. Проблема в том, на какой стадии сборки пакета их разархивировать (если это архив) и как (какой директивой) включать в пакет на заключительном этапе (%files, %doc). Первая часть проблемы: разархивация. Варианты для архивов: A1) разархивировать на стадии %prep вместе с основными исходниками в то файловое пространство, где будет происходить build самой программы (с помощью %setup, например); A2) разахивировать на стадии %install, поместив извлеченные файлы опять в то же самое файловое пространство, где произошел build программы -- туда же, куда разархивировал бы и %setup); A3) разархивировать на стадии %install сразу в то дерево, куда устанавливаются готовые файлы на этой стадии ($RPM_BUILD_ROOT). Все те же варианты есть и для отдельных файлов, не требующих разархивации: действие разархивации надо заменить на копирование. По конечному результату первые два варианта не отличаются: все равно эта дополнительная документация не участвует в компиляции программы. Аргументы в пользу первого варианта: удобство использования %setup для распаковки (для отдельных файлов это не так); в пользу второго: после внесения изменений в эту документацию (особенно актуально для отдельных файлов-описаний от упаковщика типа README.ipl) не придется заново проходить через долгую стадию %build для создания пакета, достаточно будет выполнить rpm -bi --short-circuit. (Для нормальных программ повторное исполнение %build, конечно, не должно быть проблемой, но все же.) Аргументы против второго способа: такое действие (копирование данных из SOURCES в BUILD) не совпадает с направлением остального потока данных на этой стадии: %install ставит файлы из BUILD в $RPM_BUILD_ROOT. Вторая часть проблемы: как включать файлы дополнительной документации в пакет? Мне известно три способа включения документации в пакет: B1) директивой вида %doc filename, где filename задано относительно корня дерева, в котором была произведена компиляция. При ее исполнении заданный файл копируется в нужную директорию (обычно %{_docdir}/%{name}-.../) внутрь создаваемого пакета; B2) директивой вида %doc path, где path - путь ко включаемому файлу в $RPM_BUILD_ROOT; файл предварительно должен быть установлен туда на стадии %install (в предыдущем варианте этого не требвалось); B3) указанием нужного файла среди остальных %files с предварительной его установкой на стадии %install и указание директивой %docdir того, что директория, в которую он ставится, содержит документацию (заранее уже известен набор стандартных таких директорий; man-pages и info так и ставятся). Способ B1 может быть использован в сочетании со способами разархивации в пространство компиляции A1 и A2, а остальные два B2 и B3 - в сочетании с A3. Недостаток последнего варианта мне видится в том, что не очень легко на стадии %install составить путь к месту расположения документации: например, если мы решим переразбить документацию между пакетами и включить эту документацию не в главный пакет, а в подпакет, то это уже не будет %{_docdir}/%{name}-%{version}/ и придется вносить изменения не только в %files, но и в %install (что не очень удобно: для файлов другого типа мы бы просто перенесли их указание из одного раздела %files в другой). По сути, для документации, попадающей в стандартное место (это не так для man-pages), в случаях B2 и B3 мы совершаем лишнее действие: %doc умеет сама помещать файлы, куда надо, зачем нам еще раз думать об этом при написании %install? Раз %install - лишнее действие, его можно было бы перепрыгнуть. И что тогда получаем? - Прямое копирование документации из SOURCES в создаваемый пакет. rpm этого не умеет, но можно было бы сделать %doc еще более запутанным и добавить к его возможностям и такое, например %doc -s 3 включало бы в пакет в качестве документации Source3 (в разархивированном виде, если надо); %doc стала бы чем-то похожа на %setup. Но: может потребоваться немного переработать эти дополнительные файлы докумениации во время сборки пакета на основании информации, неизвестной заранее (%packager, например), которую нельзя статически включить в исходники. Для этого сокращенный вариант %doc, включающей файлы сразу из SOURCES, не подойдет. Итак, опять возвращаемся к тому, что имеем два этапа, через которые должна пройти эта документация, на каждом из них по три варианта. Новое требование -- возможность ее динамически менять -- ничего в отношении этих способов не меняет: те же преимущества и недостатки. Теперь только между этими двумя этапами надо включить еще и переработку файлов. Чтобы сохранить преимущества всех вариантов и убрать все их недостатки, можно было бы использовать во время сборки пакета еще одно независимое файловое пространство (наряду с SOURCES, местом компиляции и $RPM_BUILD_ROOT) для подготовки дополнительной документации. Операции в нем совершались бы на двух специальных стадиях: %prepdoc и %builddoc. %prepdoc аналогична %prep, позволяет использовать %setup для разархивации документации. %builddoc вносит динамические изменения. (Для полной аналогии можно сделать %installdoc для установки файлов из нового специального файлового пространтсва в $RPM_BUILD_ROOT: может понадобиться для включения в пакет info- и man-pages из отдельных источников.) %prepdoc и %buildoc, естественно, могут быть выполнены независимо от основных %prep и %build, поэтому изменение в дополнительной документации не потребует перекомпиляции программы. После %install остается единый $RPM_BUILD_ROOT, из которого берутся файлы, перечисленные в %files, и отдельные файловые пространства, где происходила компиляция программы и где подготавливалась отдельная документация. %doc тогда могла бы принимать в качестве аргументов файлы из того и из другого пространства (различие делалось бы по какой-нибудь опции). Чем так будет лучше? Пока самый приемлемый вариант работы с дополнительной документацией это A2-B1 (разархивация в место компиляции на стадии %install и включение в пакет директивой %doc), но он концептуально неправильный: во-первых, в %install происходит установка файлов в другом направлении, во-вторых, включение в раздел %install команд для переработки документации портит его наглядность (потому что такие действия там не предполагаются). Такие изменения могут показаться несоизмеримыми с решаемой пустяковой проблемой. Но, по-моему, эти изменения в моделе сборки пакетов могут быть развиты и могут предоставить новые интересные возможности при сборке пакетов, способствовать большей ясности spec-файлов, что, наверное, немаловажно при возрастающем количестве пакетов. Если я где-то непонятно выразился, готов давать пояснения. Будут еще другие идеи, связанные с другими проблемами. -- Best regards, Ivan Z. _______________________________________________ Devel mailing list Devel@linux.iplabs.ru http://www.logic.ru/mailman/listinfo/devel