https://bugzilla.redhat.com/show_bug.cgi?id=1185019 --- Comment #3 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to Jerry James from comment #2) > Thank you for taking this review. > > (In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > > 1. gzip --best is slow, and not very efficient. Would it be possible to > > switch to xz? > > Unfortunately, no. GAP itself can read gzipped files, but does not have the > capability of reading files compressed with anything else. I will have to > look at coding up xz support and sending it upstream. For now, though, gzip > is the only possibility. > > Since gzip is required, I prefer to use --best for the space savings. On my > 6 year old x86_64 machine, compressing the files with gzip takes slightly > over 1 minute. Spending 1 minute at build time to save space on every > user's machine seems like a good tradeoff to me. (Of course, the package > might be built on an ARM machine, which would require a greater amount of > time, but it still seems like a good tradeoff, in my opinion.) OK, that's a valid trade-off. > > 2. Compression should be parallized. Maybe add a Makefile.gzip as Source1 > > > > %.gz: % > > gzip $< > > > > and call make -f ${SOURCE1} $(for i in data/*.tom; echo $i.gz) _%{smp_flags} > > I don't see the point. The compression is done once at build time. The > package is noarch, so it only needs to be built on one architecture. It > only takes a minute (or so) to do. There isn't much to save by compressing > in parallel. And, on the other hand, compressing in parallel will use more > CPU and memory at one time, which may or may not be a problem, depending on > what other builds the boxing is doing at the same time. Guidelines are pretty clear: parallelized builds are required, unless the package cannot be built that way. But it's not a problem to do it here. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review