On Sun, Aug 30, 2009 at 09:21:24PM +0100, Mike Auty wrote:
> [ "${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}" == "$(uname -r)" ] && \
> OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}"
This check is inside the get_version call, and is ultimately used to set
KV_OUT_DIR, which is in turn used for all the config checks.
The conditional part of the check means that it's only used if the
running kernel is also the one currently pointed to by the sources
variables (which were used further up in the function to populate KV_*).
I also realize on closer reading, that the above bit will never even be
reached unless the kernel sources are present.
> Otherwise it's taken from the KBUILD_DIR and then it even checks inside
> the KV_DIR's Makefile to find one. So not checking /proc/config.gz
> isn't a moot point anymore, which is not to say it's not a good idea,
> but the reason against doing it still stands. To deal with running
> kernel's, there's a get_running_version function, that will use uname to
> fill out the KV_* variables appropriately.
FYI:
get_running_version is used in one single ebuild, in the entire tree:
sys-fs/evms/evms-2.5.5-r10.ebuild
And there it's only for a warning.
> > Proposed solution:
> > ------------------
> > We need to be able to reduce user error, so we cannot simply make it
> > trust the user by default. So I propose that we add an environment
> > variable (I'm not set on the name yet), eg:
> > EXTERNALLY_BUILT_KERNEL=1
> >
> > This option will cause linux-info.eclass to consider ALL kernel option
> > checks non-fatal. That way we still get the warnings and logs, but it
> > does not stop the builds.
> I'm not sure what this is solving? It doesn't seem to reduce user
> error, it just allows users a way to override portage errors? It seems
> unrelated to config.gz and the discussion going on in the previous
> thread. I do like the idea of being able to override portage when it's
> stopping us from building (incorrectly), but surely with the capability
> to have non-fatal checks, we can try to minimize the times when
> portage/the ebuild is wrong using that, instead of a whole new override?
The great majority of CONFIG_CHECK usage in the tree is fatal already.
It only actually needs to be fatal only when it's being used to build a
module.
However, past bugs have shown lots of users complaining that a package
doesn't work, simply because they did not have the relevant option
enabled in their kernel.
This leaves us between hand-holding the basic user's kernel configuration
(exiting if the kernel config option is not enabled), and changing all
non-module instances in the tree to be non-fatal.
If we make all the non-module uses non-fatal, there will be an increase of bugs
due to users not reading the warnings.
> > When is the above NOT enough?
> > -----------------------------
> > The only time that ANY kernel sources are required is when you are
> > building an out-of-tree module. For this purpose, they must be
> > configured.
> There's a lot of ebuilds that use linux-info, and they can't all be
> out-of-tree modules. Are they misusing linux-info, or are you saying
> there's a specific instance in which linux-info requires configured
> kernel sources?
Here's a few that I know of, off the top of my head:
app-mobilephone/gnokii/gnokii-0.6.27-r4.ebuild:
CONFIG_CHECK="UNIX98_PTYS"
/usr/portage/net-print/hplip/hplip-3.9.4b-r1.ebuild:
CONFIG_CHECK="PARPORT PPDEV"
/usr/portage/net-firewall/conntrack-tools/conntrack-tools-0.9.13.ebuild:
CONFIG_CHECK="IP_NF_CONNTRACK_NETLINK"
CONFIG_CHECK="NF_CT_NETLINK"
CONFIG_CHECK="${CONFIG_CHECK} NF_CONNTRACK
linux_chkconfig_present "NF_CONNTRACK_IPV4" || \
linux_chkconfig_present "NF_CONNTRACK_IPV6" || \
If you don't have configured kernel sources, all of these ebuilds fail right
now. They are not building modules, simply userspace. The CONFIG_CHECK elements
are not prefixed with tilde to make them non-fatal.
conntrack-tools is actually even worse, as it has a kernel version check before
the config checks, which would also fail without kernel sources.
> > The check for having configured kernel sources must only be executed
> > when the modules are about to be compiled. Putting it in pkg_preinst
> > would block use of binpkgs on (related) machines.
> >
> > - If a package builds modules AND userspace, we should offer a way to
> > build the userspace only, as the user can build their modules
> > externally (or patch them into the kernel) [1]
> > - For packages that ONLY build modules, and no userspace at all, having
> > EXTERNALLY_BUILT_KERNEL=1 means that they should error out? [2]
> > (this case might be thrown into the above one).
>
> That all seems fine, but again these just seem like standard guidelines.
> Is there not already some "how to write kernel module ebuilds" page
> somewhere that documents how you're supposed to use linux-info?
If you're building modules, most of the time you're using linux-mod, not just
linux-info. There's no document or recommended behavior in the tree for the
above actually, and I'd like to introduce one.
Packages w/ USE=modules
-----------------------
app-emulation/kvm
media-libs/libifp
sys-block/open-iscsi
x11-drivers/ati-drivers
x11-drivers/linuxwacom
No choice, modules and userspace
--------------------------------
net-firewall/ipset
media-tv/ivtv
media-tv/wis-go7007
net-dialup/intel-536ep
(partial list, I just looked for a few).
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpLXNfS6pyIe.pgp
Description: PGP signature
