I would suggest the addition of a USE flag that removes the arch specific sources from all other archithetures than the one your currently using. Rationale: More than once has one of my machines run out of space. When examining the reason have been that I've run "emerge -upD world", resulting in yet a new kernel getting installed. While it is true that I most certainly should have taken precautions to stop this from happening, the fact remains that kernel sources are slotted ebuilds that require 200MB+ of space. Removing arch-specific parts of this source-tree would save up to about 40MB of space, or about 1/5 of the total footprint. The removal of this source would be very easy to do, since we allready have the arch flags, and with no consequences to the kernels, except for the fact that they can no longer compile non-native architectures. I will write the patch if you are interrested in applying it. The most reasonable thing in my mind would be to apply it to the kernel-2 eclass.
After the -dev discussion, there should be a lot of information as to why this is a bad idea. Thank-you for the suggestion, but for now I will not be adding this.
let me close it properly :)
thats better
*** Bug 117126 has been marked as a duplicate of this bug. ***
*** Bug 156291 has been marked as a duplicate of this bug. ***
So this idea was there in 2004. Why the won't fix?
Seems this bug is about saving space as well as saving bandwidth now (which implies saving space). If http://www.kernel.org/ distributed one tarball for the arch independent stuff and separate tarballs for the arch DEpendent stuff then it would be easy to implement, using use flag dependent SOURCE_URI's. They could be saving a bit of bandwidth if they did this. Either they are not interested or it's not that simple. It seems it is not that simple and I have been challenged to compile a kernel after removing the arch directories.
(In reply to comment #7) > If http://www.kernel.org/ distributed one tarball for the arch independent > stuff and separate tarballs for the arch DEpendent stuff then it would be easy > to implement, using use flag dependent SOURCE_URI's. They could be saving a bit > of bandwidth if they did this. Either they are not interested or it's not that > simple. It seems it is not that simple and I have been challenged to compile a > kernel after removing the arch directories. Well, I have implemented the changes in the kernel-2.eclass, although I only use the i386 stuff, there seems to be no big problems with this. The biggest problem is that strangely enough the archs are not totally independent. So I need to pull some x86_64 stuff to be able to compile. I have overcome these limitations, and I now have an eclass that works perfectly. Allthough I can't speak for other archs than those I use myself, which would be pentium4 and pentimM. The cross dependencies seems to be so few, that reporting them upstream when they occur would be no big task, as far as I can see. I would be happy to provide the patch for you.
(In reply to comment #8) > I would be happy to provide the patch for you. I suggest you put class in as attachment.
>The cross dependencies seems to be so few, that reporting them upstream when >they occur would be no big task, as far as I can see. Have you discussed the issue on any upstream ml? Are they at all interested? > I would be happy to provide the patch for you. By all means, attach it to this bug.
Created attachment 102911 [details, diff] Removes unneeded architecture specific code from kernel There are a few issues to be aware of: 1. This patch was originally created against the following CVS version $Header: /var/cvsroot/gentoo-x86/eclass/kernel-2.eclass,v 1.138 2005/07/21 13: 55:11 johnm Exp $. I have ported the code and created a patch from the current CVS version, but I have not tested it for more than basic functionality. 2. Since you originally declined to include this kind of patch, it has not been meant for public display. I have done a few changes that makes it more generic, and should not alter the function of the patch, but this is also not well tested. 3. The names of the use flags are perhaps not apropriate? 4. I can not gurantee that the KEEP variable which I set is not apropriate for other systems than my own. I therefore emphasize that should this patch be included, the contents of the KEEP variable should be thoroughly tested, so it does not break anything.
Created attachment 102917 [details, diff] Provides a two tier aproach to the removal issue This patch should be applied after patch 102911 . It uses a second use flag, which governs what settings should go into the KEEP variable mentioned above. By using this second use flag, one could introduce this change in the eclass in a two tier way. If you choose to use the "break_other_archs" use flag, you would willingly expose yourself to the troubles that might follow when compiling the kernel. If you choose not to use this second use flag, the KEEP variable could be kept to a safe setting, meaning we should include all architectures that might have any relevance. The "break_other_archs" flag is without effect, if "no_other_archs" is not specified. NB: I have not provided a safe setting in this patch, only the framework for doing so.
(In reply to comment #10) > >The cross dependencies seems to be so few, that reporting them upstream when >they occur would be no big task, as far as I can see. > Have you discussed the issue on any upstream ml? Are they at all interested? Sorry, I haven't taken the time to do so. But as far as I can understand, these are minor issues, like cross includes from the headers. And I have no reason to believe that they would like to keep these cross dependencies laying around. > > I would be happy to provide the patch for you. > By all means, attach it to this bug. Sorry, I was a bit dismotivated when you chose to originally declined to include this, so it took some work to bring the patch up to date. Hereby done.
