From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 18 Feb 2003 10:49:12 +0200 From: Alexander Bokovoy To: devel@altlinux.ru Subject: Re: [devel] kernel packagin', new generation Message-ID: <20030218084912.GA7506@sam-solutions.net> Mail-Followup-To: devel@altlinux.ru References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: devel-admin@altlinux.ru Errors-To: devel-admin@altlinux.ru X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.0.9 Precedence: bulk Reply-To: devel@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: Один принципиальный вопрос: как ты видишь использование этой схемы в BTE, с полностью автоматической сборкой пакета? On Tue, Feb 18, 2003 at 01:34:57AM +0300, Peter Novodvorsky wrote: > > Здравствуйте! > > Я занимаюсь созданием новых пакетов с ядром. Поговорив в ldv, rider и > другими участниками команды мои планы по проектированию новых спеков > для ядра более-менее устаканились и я вам их и представляю. > > При проектировании спека мной преследовались следующие три цели, две > конкретные и одна более абстракная: > > * Из одного spec-файла генерируется не больше одного пакета с > образом ядра. > * Все, что может собираться отдельно от ядра, собирается отдельно. > * Пакет с ядром должен собираться из конструктора, из маленьких > кусочков, причем сборка нового вида ядра не должна быть запутанным > процессом. > > Я предлагаю следующую инфраструктуру. Тарболы с исходными файлами > kernel, alsa, drm, pcmcia-cs, etc., собираются в отдельные > пакеты. Патчи тоже. Со следующей стркутурой: > > kernel-source RPM: > /usr/src/kernel-source-%{version}.tar.bz2 > /usr/share/kspec-tmpl/kernel-source-%{version}.spec.tmpl > > alsa RPM: > /usr/src/alsa-%{version}.tar.bz2 > /usr/share/kspec-tmpl/alsa-%{version}.spec.tmpl > > > %{patch_name}-kernel-patch RPM: > /usr/src/patches/%{patch_name}/* /* various patch files */ > /usr/src/patches/apply/%{patch_name} > > Планируется сделать скрипт make-kspec. make-kspec подставляет > переменные в начало spec.tmpl'ей и генерит спеки к заданным > пакетам. Например, > > make-kspec --kver 2.4.18 --modules alsa,drm,pcmcia-cs \ > --patches grsec,reiserfs --flavour multimedia \ > --release alt1 > > Оно генерит четыре спека, -- для ядра, и для трех модулей определяя в > них соответствующие требующиеся переменные. Далее, как происходит > работа с патчами: для спека ядра заполняется переменная %patches, > которая будет равна аргументу --patches. В спеке, в секции %prep есть > примерно следующее > > local applied_patches; > > tar -jxvf %kernel_tarball > pushd kernel-source-%{kversion} > for i in `echo %patches | sed -e 's/,/\ /g'`; do > applied_patches="$applied_patches,$i" > %patches_dir/apply/$i --kver %{kversion} --already-applied $applied_patches > done > > Из этого спека будет генерится пакет kernel-image-2.4.18-multimedia > с версией 2.4.18 и версией релиза alt1 и > kernel-headers-2.4.18-multimedia с той же версией и той же версией > релиза. > > Из соответствующих модулей будут генерится: > {alsa,drm,pcmcia-cs}-2.4.18-multimedia с соответствующей версией > {alsa,drm,pcmcia-cs} и номером релиза alt1, которые будут зависеть от > kernel-headers-2.4.18-multimedia. > > Единственная проблема, которая приходит мне в голову: патчи могут > конфликтовать. Но на этот случай пакет %{name}-kernel-patch может > иметь разные варианты патчей и реагировать на аргумент > --already-applied по ситуации. > > > Критика желательна. Просто необходима. А так же желательно согласие по > принципиальным вопросам. :) > > -- > Peter Novodvorsky nidd@myxomop.com > http://people.altlinux.ru/~nidd Deadheads, unite! > Kill 'em all, and let God sort 'em out > _______________________________________________ > Devel mailing list > Devel@altlinux.ru > http://altlinux.ru/mailman/listinfo/devel -- / Alexander Bokovoy --- Trouble always comes at the wrong time.