This is more of a policy-type of question then a specific bug (I need to do more testing to verify one with evms), but I wanted to raise the question. Several ebuilds that have been (semi-)recently updated, evms, and freeswan in particular, have dependencies on non-vanilla kernel modules. This is very ovbious with the latest (just added?) evms build (1.1.0-pre4). It does not compile against the crypto-sources because (observed failure, researched, but new module not actually tested - yet) the kernel module for evms does not match the tools version. Also, freeswan (1.98, where 1.97 is in crypto-sources) does seem to compile, but several bugfixes were made in the kernel modules between versions. Specifically with freeswan, the kernel modules are part of the main .tar file. It can become non-intuitive to (be able to?) merge an ebuild of version Y, but the kernel-components are older version X. Note, I'm not sure if this is necessarily a major issue, but want to bring it to light a bit. The problem is in one or two things; failing to update the kernel often enough (which may not be 'a bad thing'(tm)) or not providing enough information during the ebuild warning of the dependencies in the kernel. The perhaps best of both worlds is to issue a warning during ebuild if none of the gentoo-.ebuild kernels have the needed update, suggesting the admin update the kernel, or research the changes. OR... if there is a gentoo-.ebuild kernel with the patch, mark it as a dependency. (I.E. crypto-sources-x.y.z-r1 || some-other-x.y.z-r2 || etc...)
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.
