From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 23 Jul 2003 16:41:14 +0300 (EEST) From: Denis Ovsienko To: devel-kernel@altlinux.ru Message-ID: <20030723162931.P8840@elefant.dgtu.donetsk.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=KOI8-R Content-Transfer-Encoding: 8BIT Subject: [d-kernel] kernel-image Provides: X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 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: Wed, 23 Jul 2003 13:38:09 -0000 Archived-At: List-Archive: List-Post: Я думаю над следующим вопросом: как мне узнать, что flavour, для которого собирается ipsec_tunnel, прошёл CryptoAPI patch? Зависимость от kernel-feat-crypto тут ничего не даст. Давайте введём фичи, предоставляемые kernel-image, в данном случае все ядра, к которым прилагается kernel-feat-crypto, можно промаркировать Provides: cryptoapi-kernel. Аналогично можно объявлять другие фичи, например, O1sched-kernel, evms-kernel, xfs-kernel. Тогда зависимости userspace-пакетов и модулей можно будет вязать на эти Provides. В идеале этот Provides должен быть нарисован в соответствующем kernel-feat-* и автоматически добавляться к Provides: kernel-image, который при сборке вызвал %add_patch_list. В данном случае я-то знаю, что конкретно этот std-up CryptoAPI прошёл, но не контролировать же каждую версию и сборку для каждого flavour вручную! P.S. Для kernel-headers Provides: -kernel тогда тоже должен выставляться. -- DO4-UANIC