[gentoo-kernel] linux-info usability

[Daniel Drake]

Hi,

[ I have discussed this with johnm on IRC but we didn't really come to a 
conclusion, so I'm posting here in hope of hearing other opinions too ]

We have two new eclasses in the tree: linux-mod and linux-info.

linux-mod relies upon and uses lots of linux-info and I think we've done a 
good job of making module installation smooth with that.

I was under the impression that linux-info was designed to provide things like 
kernel version info and config checking to ebuilds - $KV is currently defined 
by portage, but we want to stop portage doing this, and have it done through 
an eclass.

Currently, pretty much any function in linux-info relies on you having called 
the get_version so that it goes and looks at /usr/src/linux and parses the 
version info, etc. linux-mod handles this for you automatically.

For ebuilds that directly inherit linux-info in order to get this kind of info 
(i.e. excluding the ones that go through linux-mod), 99.9% of them are going 
to need to call the "get_version" function from in that ebuild.

So I think it makes much more sense for that to be called from an exported 
pkg_setup() in linux-info.eclass so that ebuilds do not have to worry. There 
are a few reasons for this:
  - Less work to do when converting all the ebuilds
  - Less confusion for people writing new ebuilds who aren't sure of what 
"get_version" does or who don't know that it makes things like ${KV_FULL} 
available
  - ${KV} was previously available hassle-free through portage and I think we 
should keep it as close to this as possible
  - I don't feel it makes _sense_ for the ebuild to have to call that function 
when its implied usage is to provide version info anyway, and there really 
aren't any other sensible uses.

I think we should add a pkg_setup to linux-info.eclass which calls get_version 
which simply prepares variables such as $KV_FULL (2.6.10-rc3) and $KV_OUT_DIR 
(/usr/src/linux). Any ebuild inheriting this eclass directly is going to want 
to use those variables.
(We will have to make sure this pkg_setup is not exported/executed if 
linux-mod has been inherited since linux-mod exports its own functions - but 
this is another issue that I think we can take care of fairly easily)

Another alternative is to use the current linux-info as a base eclass (i.e. it 
just provides functions for use by other eclasses and is not designed to be 
inherited by actual ebuilds), and then to provide 2 interface classes: one for 
simplifying compilation/installation of modules, and another which provides 
simple kernel path/version information that is required by many ebuilds.

This would involve:
  - Renaming the current linux-info to linux-base.
  - No ebuilds would directly inherit linux-base, this is only a support eclass
  - linux-mod would inherit linux-base (unchanged otherwise)
  - a new linux-info would be created, which inherits linux-base and provides
    pkg_setup to get the version/path info ready
  - all ebuilds that only require basic kernel info would inherit the new
    linux-info


How does everyone feel about this? Hopefully I've raised 2 issues here:
1. Should users really have to call get_version to get info that pretty much 
all users are going to need
2. If we agree to automate the above, then should we form a base class 
hierachy or should we just hack linux-info a little

I am prepared to do the work to get this in place - I think it is a sensible 
improvement to make.

Thanks,
Daniel

--
gentoo-kernel@g.o mailing list