Re: [gentoo-dev] kernel-mod.eclass addition + clean up

[Daniel Drake]

On Monday 01 November 2004 06:23, Henrik Brix Andersen wrote:
> Yeah, I was uncertain about kernel-mod_src_compile() as well. Just
> didn't want to take it out since sys-apps/cloop depends on it. We could
> leave it out and fix sys-apps/cloop accordingly?

Sounds good, but you should check it with the cloop maintainer first. Also ask 
about the zlib stuff, according to grep, cloop is the only ebuild that uses 
it. I think we should move the zlib stuff into the cloop ebuild and take it 
out of the eclass.

> Yes, that's why I included kernel-mod_need_subdir_to_m(). Ebuilds which
> require more than the simple sed statement can do:
>
>  if kernel-mod_needs_subdir_to_m
>  then
>   ...
>  fi
>
> Will this do?

Perhaps some comments around the _subdir_to_m function would be appropriate - 
but other than that, I don't think theres much we can do.

> Many ebuilds rely on having more than ${KV} available.
> kernel-info_getversion() provides ${KV_MAJOR}, ${KV_MINOR} and
> ${KV_PATCH}.

Ok, how would you feel about removing the ${KV} stuff from portage.py and just 
making the ebuilds that currently use it convert to using kernel-info? Or, we 
could easily extend portage to set KV_MAJOR etc. But what I'm getting at is 
that we should only do this in one place - and where should it be? My view is 
that it should be done in the eclass.

Thanks,

Daniel

--
gentoo-dev@g.o mailing list