Created attachment 380712 [details, diff] cpupower-partial-unpack.patch Currently cpupower unpacks a full linux kernel source tarball (500-600MB on disk), to get to the ~500kB of souces it needs. A simple ebuild patch like this will make it unpack only what's actually used. Of course any comments/tweaks/rejection are welcome.
A couple of notes: 1. Using ${A} like that is a bit ugly, and will break if another file is added to SRC_URI. I would specify the actual file name: linux-${PV}.tar.xz. 2. Needs || die.
Also, we should either depend on a new-enough tar that understands the .xz extension, or use an explicit pipeline, like this: xz -cd "${DISTDIR}/linux-${PV}.tar.xz" | tar -xf - ...
Thanks for the feedback. I considered the ugliness of $A and that should be fixed. WRT tar versions, xz (-J) is supported in 1.22 or later, and 1.23 was stabilized 4 years ago. All versions older than 1.22 were removed >3 years ago. Is an explicit tar dep still warranted?
Has it really been that long? I guess that's probably ok then.
How about replacing the attached patch with the corrected version after the feedback?
Created attachment 380720 [details, diff] cpupower-partial-unpack.patch Revised patch here
Please note, this fixes one problem but completely ignore another. Yes it's nice to speed things up and not waste IO for fun, however, on arches like arm we may not even have a generic kernel sources installed, and this will force >100MB to be downloaded. Wouldn't a better solution be for the maintainer to extract what is needed and make a nice tiny tarball?
(In reply to Rick Farina (Zero_Chaos) from comment #7) > Wouldn't a better solution be for the maintainer to extract what is needed > and make a nice tiny tarball? Maybe, but that would mean more work for version bumps. I would consider that a separate enhancement request.
(In reply to Mike Gilbert from comment #8) > (In reply to Rick Farina (Zero_Chaos) from comment #7) > > Wouldn't a better solution be for the maintainer to extract what is needed > > and make a nice tiny tarball? > > Maybe, but that would mean more work for version bumps. I would consider > that a separate enhancement request. It has been asked before, and I have absolutely no plans in doing anything like that That's why I'm only bumping major versions, 3.14 to 3.15 to 3.16, so I can reuse the linux-X.X.tar.xz you have to download anyway for {vanilla,gentoo}-sources
in fact I'll propably drop whole separate cpupower package at some point, and help robbat2 wrt bug 507118, and migrate cpupower back to there, adding USE flags to the ebuild, or possible create a -meta package of somekind the point of separate cpupower was to get quick up-to-date replacement with init script for the obsolete cpufreq-utils and cpufreqd but this bug is not for that, so lets keep it away from here
patch in tree, also ran `diff` of `strings` output of libcpupower.so.x.x.x to verify they match, and they do, and diff on cpufreq.h and they match also because Makefile has some 'include's, this is not necessarily full proof safe
