Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 5477 - How do we handle ebuilds with kernel module dependencies?
Summary: How do we handle ebuilds with kernel module dependencies?
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 1477 28846
  Show dependency tree
 
Reported: 2002-07-23 16:56 UTC by Brian Rozmierski
Modified: 2005-08-20 05:14 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Rozmierski 2002-07-23 16:56:33 UTC
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...)
Comment 1 Brandon Low (RETIRED) gentoo-dev 2002-09-06 18:13:01 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.
Comment 2 Brian Rozmierski 2002-10-18 22:44:44 UTC
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.
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2005-08-20 05:14:40 UTC
Closing an obsolete stale bug.