Added an use option (lufsnokernel) to the ebuild to alow the building of lufs without building the kernel. Reproducible: Always Steps to Reproduce: 1.fixed 2. 3. *** /usr/portage/sys-fs/lufs/lufs-0.9.7.ebuild Tue Nov 25 18:25:42 2003 --- /home/portage/overlay/sys-fs/lufs/lufs-0.9.7.ebuild Fri Mar 19 18:44:31 2004 *************** DEPEND="virtual/linux-sources" *** 11,17 **** RDEPEND="" KEYWORDS="~x86 ~amd64" SLOT="0" ! IUSE="lufsusermount" src_unpack() { unpack ${A} --- 11,17 ---- RDEPEND="" KEYWORDS="~x86 ~amd64" SLOT="0" ! IUSE="lufsusermount lufsnokernel" src_unpack() { unpack ${A} *************** src_unpack() { *** 35,40 **** --- 35,53 ---- epatch ${FILESDIR}/gentoo-gcc332fix-${PV}.patch } + src_compile() { + + local myconf= + + use lufsnokernel && myconf="${myconf} --disable-kernel-support" + + ./configure ${myconf} || die + + einfo "Make" + make all || die "Failed to build lufs!" + einfo "Make completed" + } + src_install () { dodoc AUTHORS COPYING ChangeLog Contributors INSTALL \ NEWS README THANKS TODO
Created attachment 27669 [details, diff] added --prefix=/bin to the config changed local myconf= to local myconf="--prefix=/usr "
Created attachment 31792 [details, diff] patch for disablekernelsupport This was apparently added to lufs-0.9.7-r2, but has two (or maybe three) problems: - IUSE calls the USE flag "disablekernelsupport" while the rest of the ebuild uses "nokernelsupport". This patch makes it use "disablekernelsupport" throughout. - Even with "disablekernelsupport" enabled it still calls various functions from the kmod eclass which require the kernel source to be writable. This is obviously unnecessary when the kernel module is not built. This patch attempts to fix that. - The new use flag doesn't show up in ufed. This is probably because it's not in /usr/portage/profiles/use.local. I don't know why it's not listed there. Please note that I've only tested this with "disablekernelsupport" enabled.
Can you please try if this is fixed by Bug 67212, comment if it works and add a dependency?
I believe this bug is no longer relevant with the latest changes to the lufs ebuild.