When testing behavior of genkernel with menuconfig, I tried running more than one of them, thinking that an unchecked condition might exist. My kernel configuration information was wiped out because of multiple runnings of it. Reproducible: Didn't try Steps to Reproduce: 1.run genkernel 2.run genkernel again at the same time 3. enjoy at least missing kernel config Actual Results: lost my kernel config, worse might also be possible Expected Results: tested to see if genkernel was already running
ok, can I say WTF here ?? closing bug as WONTFIX it's moronic to have to make a check like that...
Yes, It's moronic to check for multiple running genkernels... especially when it screws up an already running one! Gheeze, programs should have the right to clobber your configuration whenever they want to. Seriously, just make a lockfile. (I think that's what it's called) We really don't want people to run genkernel in one VT and forget about it, then go back to their konsole and start another one, doing make mrproper right over the almost complete other one.
sorry, a lockfile would cause more problems then good, especially, if someone breaks out of a genkernel and the lockfile still exists .... we've got more important things to worry about right now with genkernel 3.0, that is way way way way way way way down on the list with the idiot-proofing stuff, usability, stability, and features come first.
I switched it to enhansement. I don't mean to be a jerk, so that is a bit of a compromise. Idiot proofing is a feature, and believe me I know plenty of idiots (myself being a prime example) A disclaimer for when the lockfile stops use of the program: Error, Lock File exits. remove /tmp/blah if there is no other genkernel running. Also, it is possible to catch the control-c interupt, and remove the lockfile as part of die() Idiot proofing needs to be a part of the basic foundation of the system, and is a major feature. If you don't want a bug assigned to you, assign it to me, or something. I won't reopen the bug again, I'll just be a bit more questioning of the quality of the software. I think I've heard thet 95% of the computer errors come brom user/programmer error... If there is no convinient lockfile system for gentoo scripts, then i propose that a new bug be made that asks for a standard lockfile ssytem or library that will allow all scripts and programs to be a bit more idiot proof. So, If you think that's not a horrible idea, we can make a new bug and say that this one depends on that. So, reasign, or change the bug please, I know this is valid, and I want it somewhere in cache so people don't think that they are done when all of the non reliabilty features are complete. There might even be some people who are willing to add this feature/ help with genkernel I use genkernel becaus4e I don't know how to do busybox and initrd with the other procedure.
it WILL NEVER be a lock file. Seriously, it would definately cause more problems. If it was a different language other than shell, perhaps it would be doable, but I'm not going to attempt to do that in shell. The other alternative is to scan 'ps' for the running process, but that test fails as well if you're building 2 different kernels simultaneously (which is also where your lock file example breaks down, as just doing a /tmp/blah has no way to tell which kernel directory you're compiling, etc, so it would prevent people properly using multiple instances of genkernel). I'll leave it open for now as enhancement, but I may close it again if it annoys me too much, as this is something that will _very_ rarely happen. It's kind of like saying you need to add a safeguard so someone that's finished a build from stage1, doesn't go into another console and mke2fs -j /dev/hda1 after the fact. I just don't have much tolerance for anyone that would do something like that.
I'd like to interject something here. I'm old enough to have done windows tech support for an ISP in 1993 when everyone was using Trumpet Winsock to connect to the Internet, and we had to develop our own SLIP scripts to handle TCP/IP connections. One of the things I learned was that in any technical environment used by a lot of people, the behavior of the user base resembles the behavior of water in a container or plumbing system. If there's even a very small hole, a very small amount of water will leak through it. If there's any possibility of someone screwing up on something, someone sooner or later will. This has nothing to do with idiots, and everything to do with plugging holes and providing efficient and effective guidance. Simultaneous kernel builds (or builds of anything from the same source) _can_ interact destructively, however if there are cases where simultaneous builds of related sources are appropriate, an advisory lockfile or some other advisory mechansim would be entirely appropriate. This puts the choice immediately back in the hands of the user of the software. e.g.: "Genkernel has detected another kernel build in progress, or possibly one that was aborted prematurely. If another kernel build is in process, you may lose data or both builds may fail. Continue? [Y/n]" IMHO, "idiot-proofing" a mass-user software system is as much a feature as making sure that any system that handles fluids - a roof, a plumbing system, a tank - doesn't leak. It's the difference between usability and excellence. I hope no one takes offense at this. The gentoo dev people are working hard and gentoo is rapidly gaining popularity, as I can tell from posts to the LUG mailing list I host in Austin. This makes the devs' work all that much harder.
I think I can make the program catch the kill signal / control-c and run the delete lockfile portion... also the lockfile can be called /tmp/username/genkernel-kernelversion ?
[[ Reassigning ]]
This is solved in genkernel-3.0.2_rc1. Thanks!
