From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Comment-To: Sergey Vlasov To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] kernel-std-up-2.4.25-alt2 rebuild failed? In-Reply-To: <20040330125033.GC5598@master.mivlgu.local> (Sergey Vlasov's message of "Tue, 30 Mar 2004 16:50:33 +0400") References: <20040330110448.GB3757@master.mivlgu.local> <20040330111445.GD18144@master.altlinux.ru> <20040330113303.GA5598@master.mivlgu.local> <20040330114231.GO18144@master.altlinux.ru> <20040330115914.GB5598@master.mivlgu.local> <20040330125033.GC5598@master.mivlgu.local> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Tue, 30 Mar 2004 16:25:26 +0300 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.4 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: Tue, 30 Mar 2004 13:26:02 -0000 Archived-At: List-Archive: List-Post: Sergey Vlasov writes: >> > Именно. Причём заваливать будет главным образом мантейнеров >> > "нестандартных" ядер (wks, aw, ...). >> По этому поводу с нашей стороны(aw) есть предложение обеспечить сборку не >> только последнего std, а и всех остальных ядер. В том >> числе и сборку ядер разных версий. Это легко достигается путем >> размещения патчей в разных каталогах и прикладывания их к разным >> версиям/flavour-ам ядер при сборке. Требуется только подправить в эту >> сторону kernel-build-tools и разработать систему именований и тактику >> работы. > > И как это будет выглядеть? > Сейчас уже частично есть этот механизм по отношению к версиям ядер, нужно только развить его в сторону умения прикладывать патчи к определенному flavour-у/subversion и определить порядок и приоритеты приложения патчей для конкретного flavour/version/subversion. >> Зато выгода налицо - ядра будут собираться независимо от >> изменений в fix-ах и feat-ах. Из минусов могу предположить некий оверхед >> в kernel-feat|fix-ах и несколько большее количество kernel- пакетов. >> Зато все ядра будут живые и пересобираемые и решение о включении >> какого-либо патча будет принимать мэйнтейнер ядра, а не некто, >> добавляющий этот патч в kernel-fix. > > Не получится ли в результате kernel-fix-%name-%flavour? Нет, конечно. Все будет в том же пакете. Спек несколько усложнится, это да. Симлинки можно будет попользовать, чтобы пакеты не распухали. Если мэйнтейнер определенного ядра решит отслеживать патчи самостоятельно, то для этого ядра будет сделаны подкаталоги в соответствующем kernel-fix или kernel-feat и в kernel-image патчи будут прикладываться вот таким образом: %apply_patches 2.6.3 flavour Опять же всегда можно работать и по текущей схеме, прикладывая патчи например так: %apply_patches 2.6.3 std26 Или так: %apply_patches 2.6.3 -- Best regards, Ed V. Bartosh