From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 22 May 2005 17:13:12 +0400 From: "Konstantin A. Lepikhov" To: ALT Linux Kernel Devel Mailing List Message-ID: <20050522131312.GA30337@lks.home> Mail-Followup-To: ALT Linux Kernel Devel Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operation-System: ALT Linux Sisyphus (20050505) 2.6.11-wks26-up-alt2 User-Agent: Mutt/1.5.8+cvs20050213i X-AV-Checked: ClamAV using ClamSMTP Subject: [d-kernel] RFC: =?koi8-r?b?19nUxdPO0cDdycog0sXMydogxMzR?= kernel-modules X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 13:14:28 -0000 Archived-At: List-Archive: List-Post: Hi! В связи с происходящими в последнее время конфликтами по релизам модулей для ядер, есть мысль как это можно разрулить - на этапе сборки модуля ставить module_release вида @kreleasebuild@, где kreleasebuild является строкой вида %release.%kcode.%krelease. Что это даст? Во-первых, теперь релиз будет вытесняющим, т.е. при смене kernel-version версия модуля будет по-любому вытеснять предущую, т.к. будет иметь KERNELCODE явно больше, чем предыдущая версия ядра. Во-вторых, релиз ядра будет влиять только на локальные сборки модулей в пределах одного KERNELCODE. Конечно, это не убережет от ситуации вида "кто-то собрал старый модуль с новым .spec", но это уже будут локальные проблемы такого пользователя. %kcode с точки зрения buildmodules может выглядеть так: --- buildmodules.orig 2005-02-12 13:24:18 +0300 +++ buildmodules 2005-05-22 16:59:37 +0400 @@ -14,6 +14,7 @@ KERNEL=`find out/RPMS/ -type f -name "ke RELEASE=`rpm -q --qf "%{RELEASE}\n" -p $KERNEL` VERSION=`rpm -q --qf "%{VERSION}\n" -p $KERNEL` BUILDRELEASE=`echo $RELEASE|sed -e "s,alt,,"` +KERNELCODE=`kernelversion_code $VERSION` buildspec() { @@ -25,7 +26,7 @@ buildspec() specout="`dirname $spec`/`echo $real|sed -e "s/\.spec/-$TYPE.spec/"`" realspec=`basename $specout` cp -f $spec $specout - subst "s,@kversion@,$VERSION,;s,@krelease@,$RELEASE,;s,@kreleasebuild@,$BUILDRELEASE,;s,@kflavour@,$TYPE," $specout + subst "s,@kversion@,$VERSION,;s,@krelease@,$RELEASE,;s,@kreleasebuild@,$KERNELCODE.$BUILDRELEASE,;s,@kflavour@,$TYPE," $specout PACKAGES=`rpmquery -q --qf="%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" --specfile $specout|sed "s,i686,i586,"` NEEDUPDATE=0 for package in $PACKAGES ;do а скриптик для получения kcode будет выглядеть вот так: #!/bin/sh # Small script to get the kernel version code # Made by LAKostis for ALTLinux kernel-build-tools package. # Based on the kernelversion_major script # from modutils package made by Dmitry V. Levin. pick1() { eval 'echo $'"$pick_index" } pick() { local OLD_IFS="$IFS" local delimiter="$1" shift pick_index="$1" shift IFS=" "$delimiter pick1 $* IFS="$OLD_IFS" unset pick_index } release="$1" [ ! $release ] && release=$(uname -r) kver=$(pick - 1 $release) version=$(pick . 1 $kver) patchlevel=$(pick . 2 $kver) sublevel=$(pick . 3 $kver) # from kernel Makefile echo `expr $version \\* 65536 + $patchlevel \\* 256 + $sublevel` Данный скрипт можно положить либо в modutils, но мне кажется лучше в kernel-build-tools, поскольку нужен он только сборщикам, обычные пользователи могут этот CODE из хидеров вытащить. -- WBR, Konstantin chat with ==>ICQ: 109916175 Lepikhov, speak to ==>JID: lakostis@jabber.org aka L.A. Kostis write to ==>mailto:lakostis@pisem.net.nospam ...The information is like the bank... (c) EC8OR