In 99% cases user does not need arch support except of his own. Deleting unnecessary files frees > 20% of disk space: 485904 linux-2.6.37-gentoo-r4 380564 linux-2.6.37-gentoo-r4 (with x86 arch only) This feature can be implemented as a use flag for flexibility Reproducible: Always
+1 Here it's very usefull on embeded system, and minimal system. Too for the FS speed on slow media.
And if it can be excluded from the tar decrompression...
Does excluding those directories require any further modifications? I'd think Makefiles would fail because of those directories not being present.
(In reply to comment #3) > Does excluding those directories require any further modifications? > I'd think Makefiles would fail because of those directories not being > present. Absolutely no. At least when compiling for x86/x86_64 arch (checked with 3.4.35 kernel). The only problem may be applying patch over kernel tree with absent (unneded) arch directories, but in this case I think patch can silently ignore those ones. I have no working ebuild ATM but AFAIK such usecase is present in qt* packages where for each package (e.g. qt-gui or qt-core) only needed directories are unpacked from dist tar file.
Working myself through the list of eclass bugs, so evaluating this one: > This feature can be implemented as a use flag for flexibility. We can't do this for everyone as it would break patches that involve patching arch directories (we can however defend ourselves, suggesting they use /etc/portage/patches and/or disable the USE flag), there are probably also people that share the directory and so on... The default should for these various reasons be as unmodified as possible. I'm not sure what a sane USE flag name for this would be, "noarch" isn't really correct, "multiarch" would draw attention to "support for multiple archs" which is kind of weird, "embedded" would be ambiguous (for one, it may remove arches, for another it would add arches) so I'm not sure if there is a clear and sane name. Do you have an idea for a clear and sane USE flag name? > The only problem may be applying patch over kernel tree with absent (unneded) arch directories, but in this case I think patch can silently ignore those ones. This may be problematic if you want it excluded from the tar decrompression and not affect the patches, since what actually happens is that it first takes linux-3.8 and then it patches it with patches 3.8.1 up to 3.8.6 and any other patches that were given. So, from each patch it would have to remove the patches against arch directories on the fly; which makes this more complex to implement than a simple remove the directories. The other method would be to just remove it when installing, it wouldn't trim down the work the eclass does but it at least results in the resulting install to take less disk space.
As per comment #5, this could potentially break our patching system for the gain described.
