Summary: | How do we handle ebuilds with kernel module dependencies? | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Brian Rozmierski <brianr> |
Component: | [OLD] Unspecified | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | azarah, chutz+bugs.gentoo.org, dev-portage, drobbins, flash3001, karltk, radek, styx |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 1477, 28846 |
Description
Brian Rozmierski
2002-07-23 16:56:33 UTC
If ebuild require things that are in the kernel-source by default then they simply need to know how to compile and install those modules, if they require certain patches or a certain kernel source set, then they should depend appropriately... for instance if USE=crypto isn't set and someone is trying to install a package that needs something that is only supported with the crypographic patches to the kernel then we should warn the user about this and fail. Yes, but that's only half the answer... Sticking with a system built using the crypto-sources kernel (currently at 2.4.19-r7)... The EVMS modules in the kernel (which are pre-merged) are 1.0.1 ish. (Might be 1.0.0 or a -pre version, but suffice it to say the userspace evms code breaks after 1.0.1). Right now in portage the _only_ evms userspace utilities in the tree are 1.2.0, which are incompatible with the EVMS modules pre-merged into crypto-sources. In effect, 'emerge -u world' and you break evms with no way to fall back (other then get the file out of CVS and drop into portage.local...). IPSEC with FreeS/Wan is similiar - the pre-merged patch in crypto-sources is 1.97. The current userspace ebuild (which normally would also patch the kernel, but it's disabled, IIRC) is 1.98. Luckily they will happily co-exist, but any patches kernel-side aren't reflected, and users may, incorrectly, think they have both user/kernel version 1.98. IMHO, the problem is in the dependency system (somewhere). The devs know that you can't use the EVMS userspace ebuild unless you have merged EVMS into the kernel first. It's also known that EVMS is in several of the kernel builds (beyond crypto-sources I don't know -- it's the only one I use... I'll call them 'A' and 'B' for conversation sake). What's needed is to say that EVMS 1.2.0 depends on crypto-sources-2.4.19-r10 or higher if and only if some version of it is installed. The same repeats for 'A' and 'B' with their respective versions, and as a final dependency you must have merged either 'A', 'B', or 'crypto-sources'. The same would apply for the other kernel-dependant packages as well. It would make dependancy checking more complicated, but infinately more flexable. Closing an obsolete stale bug. |