should /usr/bin/genkernel be a symlink to /usr/share/genkernel/genkernel.sh If it were, it would be a lot easier to develop genkernel Reproducible: Always Steps to Reproduce:
I don't really see the problem here. ``man hier''... /usr/share: This directory contains subdirectories with specific application data, that can be shared among different architectures of the same OS. Often one finds stuff here that used to live in /usr/doc or /usr/lib or /usr/man. /usr/bin: This is the primary directory for ** executable ** programs. Most programs executed by normal users which are not needed for booting or for repairing the system and which are not installed locally should be placed in this directory. ... So it needs to be shifted over to /usr/sbin.
Tim, I think genkernel is designed to be usable for any user. of course install features won't be available for non super user... but for this tool to be usable for cross compiling/rescue /usr/bin/ is fine. Now, that said.. I don't care where it is, so long as it's just a symlink for easier patching.
``any user'' doesn't have access to the source tree? Remember that compiling is a read-write operation. Secondly, I don't see what the patching problem is - the tarballs contain things in one bunch so the patches should designed for them rather than the real filesytem.
Tim, re: /usr/sbin vs /usr/bin >``any user'' doesn't have access to the source tree? genkernel supports/should support options to choose where your kernel sources are. A user compiling vis own kernel in vis own home dir with genkernel was intended to be supported. I say can that, because that's the reason cited by brad when he nuked my lockfile feature request. lockfiles can still work, if they are on a per source tree basis... so that bug is reopened It really scares me that stuff is written in the source directory during compilation. Is there an option in make that says use an alternate directory for work/treat the source as a read-only area? > I don't see what the patching problem is maybe not a big problem, but it requires way more work to make changes (see OT comment) .. or dealing with multiple patches... it just feels unclean to me... **OT** I don't care where the file is linked to, I just think that it should stay in the /usr/share/genkernel directory... I'm going to try to make my patches for genkernel work with the packages... but.. I have no idea how to do this efficiently! /var/tmp/portage/blah... goes away after an install... and I really do hate repackeging and running ebuild /path/to/ebuild digest.. (there is a bug asking for better/easier software development with portage).. then diffing the sources and making the new ebuild use the patches... ** I'm working on genkernel again tonight, and I have already moved it in my implementation.. Note: this is a "general type" bug.. I think all of this type application should use symlinks to their respective bin directory.
Re: "**OT**" patch issue. Just make a patch which will be run in the ebuild where all the files are in their relevant locations. Re: Lockfiles - I'm not going to implement them. Considering the very messy outcome of the lockfiles implemented in Portage 2.0.50; Genkernel won't have them. Probably ever. I have, though, implemented a collision-detector and a system to move things out of the way if multiple builds are detected, so that issue is solved. Re: "Is there an option in make that says use an alternate directory for work/treat the source as a read-only area?" - not AFAIK. This would be very messy to implement on the kernel Makefiles since output files usually get written into the same directory and then you have the very long-winded include chains and thus forth. Would be nice if there was one. I guess I might as well move it over in the next Genkernel release when I add it to Portage since it won't cause any harm.
Tim, I've implemented ebuilds in my branch, and they seem to work ok with control-c and other abnormal exiting Re *OT* make /compile options... I just realized that KNOPPIX has an overlay type file system ... or could benefit from one... maybe the same technology could be used to make a transparently separated make/compile enviornment?
Overlay: Yes, but that would involve you having to set up a whole GCC and essentially mini-Linux inside the chroot to build stuff; and then have an external script to move stuff out. Much easier to just copy the source tree to another place which one can write to and declare TEMP= on the command line to something similar as well.
In the ebuild for genkernel-3.0.2_rc1; closing as FIXED.
