Re: Something like nocompress DEB_BUILD_OPTION
Hi Dmitrijs, Dmitrijs Ledkovs wrote: This should be a standard interface via DEB_BUILD_OPTIONS, because dh_builddeb / dpkg-deb is not the only way to build compliant binary packages. Policy §4.9 explains: Both binary-* targets should depend on the build target, or on the appropriate build-arch or build-indep target, if provided, so that the package is built if it has not been already. It should then create the relevant binary package(s), using dpkg-gencontrol to make their control files and dpkg-deb to build them [...] Do any packages violate that? Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121121094837.GA21009@elie.Belkin
Re: Something like nocompress DEB_BUILD_OPTION
* Jonathan Nieder jrnie...@gmail.com, 2012-11-21, 01:48: This should be a standard interface via DEB_BUILD_OPTIONS, because dh_builddeb / dpkg-deb is not the only way to build compliant binary packages. Policy §4.9 explains: Both binary-* targets should depend on the build target, or on the appropriate build-arch or build-indep target, if provided, so that the package is built if it has not been already. It should then create the relevant binary package(s), using dpkg-gencontrol to make their control files and dpkg-deb to build them [...] Do any packages violate that? pax eats its own dog food: it builds binary packages using pax, avoiding dpkg-deb (except for cross-compiling). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121121110117.ga3...@jwilk.net
Re: Something like nocompress DEB_BUILD_OPTION
Dmitrijs Ledkovs xnox at debian.org writes: Gzip is ok, but many packages these days use xz -9 --extreme deb xz is fine but -9 is abuse of the flexibility… maybe I should export XZ_DEFAULTS=--memlimit=150MiB in my build chroots… hmm… something to think about… (for m68k, I might actually use less, setting it to 80MiB would force compression down to -4 which, with --extreme possibly, is enough, there) //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20121120t204607-...@post.gmane.org
Re: Something like nocompress DEB_BUILD_OPTION
On Tue, 2012-11-20 at 19:48:25 +, Thorsten Glaser wrote: Dmitrijs Ledkovs xnox at debian.org writes: Gzip is ok, but many packages these days use xz -9 --extreme deb xz is fine but -9 is abuse of the flexibility… maybe I should export XZ_DEFAULTS=--memlimit=150MiB in my build chroots… hmm… something to think about… (for m68k, I might actually use less, setting it to 80MiB would force compression down to -4 which, with --extreme possibly, is enough, there) XZ_DEFAULTS will not be honoured because dpkg-deb is not using the xz command, but the liblzma shared library. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121120231250.ga21...@gaara.hadrons.org
Re: Something like nocompress DEB_BUILD_OPTION
On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote: On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote: Okay. I did some tests with various packages. From binary only to text only. Thanks for the tests Bastian. It would still be nice to see a bigger sample, if the tests only consisted of these 4 packages, though. Package | gzip -6 | gzip -9 | gzip | xz -1 --+--+-+- libc6 | 4339010 | 4321933 | 0.5% | 2938132 perl-modules | 3874170 | 3822719 | 1.5% | 3248392 gnome-user-guide | 9217494 | 9172395 | 0.5% | 7589076 linux-image-3.2.0-4-amd64 | 32928159 | 3258 | | 25945856 gzip -9 is always much slower then gzip -6. It is at most 2% better. xz -1 is usualy faster then gzip -9 and much better. However most packages only needs seconds to compress, so the difference will no really matter. So instead of switching to gzip -6, a switch to xz -1 would make more sense in term of size and also speed. So my proposal would be: - Don't do anything for Wheezy. Any change may break the CD creation. - Switch to xz per default for Jessie. xz -3 is often faster in compressing stuff then gzip -9. -6 needs a lot of memory, especially for compressing the files, so reducing the default to -3 may make sense and does not cost much. I've already mentioned in some other thread that for dpkg 1.17.x (that is after wheezy), I'll be switching dpkg-deb to xz as the default compressor, as that seemed the consensus; but that does not mean that if the default compression level for gzip is suboptimal (as it seems it is), that cannot be changed too. For changing xz default compression level I'd like to see the implications on a wider dataset, also we should take into account that compression is only done once, so I don't think that's such an issue, if the time and memory are not really onerous. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121120232155.gb21...@gaara.hadrons.org
Re: Something like nocompress DEB_BUILD_OPTION
On 20 November 2012 23:21, Guillem Jover guil...@debian.org wrote: On Sat, 2012-11-10 at 13:52:22 +0100, Bastian Blank wrote: On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote: Okay. I did some tests with various packages. From binary only to text only. Thanks for the tests Bastian. It would still be nice to see a bigger sample, if the tests only consisted of these 4 packages, though. Package | gzip -6 | gzip -9 | gzip | xz -1 --+--+-+- libc6 | 4339010 | 4321933 | 0.5% | 2938132 perl-modules | 3874170 | 3822719 | 1.5% | 3248392 gnome-user-guide | 9217494 | 9172395 | 0.5% | 7589076 linux-image-3.2.0-4-amd64 | 32928159 | 3258 | | 25945856 gzip -9 is always much slower then gzip -6. It is at most 2% better. xz -1 is usualy faster then gzip -9 and much better. However most packages only needs seconds to compress, so the difference will no really matter. So instead of switching to gzip -6, a switch to xz -1 would make more sense in term of size and also speed. So my proposal would be: - Don't do anything for Wheezy. Any change may break the CD creation. - Switch to xz per default for Jessie. xz -3 is often faster in compressing stuff then gzip -9. -6 needs a lot of memory, especially for compressing the files, so reducing the default to -3 may make sense and does not cost much. I've already mentioned in some other thread that for dpkg 1.17.x (that is after wheezy), I'll be switching dpkg-deb to xz as the default compressor, as that seemed the consensus; but that does not mean that if the default compression level for gzip is suboptimal (as it seems it is), that cannot be changed too. For changing xz default compression level I'd like to see the implications on a wider dataset, also we should take into account that compression is only done once, so I don't think that's such an issue, if the time and memory are not really onerous. While I appreciate the discussions around default compression algorithms and their setting, I'd rather this thread to stay on-topic. Does the idea of providing a standard interface to disable compression make sense? In the approximately similar fashion that noopt and nostrip are justified? This should be a standard interface via DEB_BUILD_OPTIONS, because dh_builddeb / dpkg-deb is not the only way to build compliant binary packages. Please continue discussing default compression options, but please use another thread/topic. Just as I do now, I will continue to want the nocompress option regardless of current or future default/non-default compression algorithms and options. I'd like to gather consensus on how (in)sane this idea is though before submit a patch for debian policy. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUh_y+X=bzga5rldy+fvvmcmso0gwhamibc28y+erga...@mail.gmail.com
Re: Something like nocompress DEB_BUILD_OPTION
On Fri, Nov 09, 2012 at 07:48:22PM +0100, Guillem Jover wrote: There used to be a single global default level (9) for all compressors, which got changed in 2010 to be backend specific, but only xz and lzma were reduced to 6. I don't have any problem with changing gzip (to its upstream default!) if as shown it's a vast improvement speed vs space. I can certainly do that for dpkg 1.17.x, some more numbers would be nice though, as in different types of data.tar, for example, but I would not expect any surprises here, mostly just for reassurance. Okay. I did some tests with various packages. From binary only to text only. Package | gzip -6 | gzip -9 | gzip | xz -1 --+--+-+- libc6 | 4339010 | 4321933 | 0.5% | 2938132 perl-modules | 3874170 | 3822719 | 1.5% | 3248392 gnome-user-guide | 9217494 | 9172395 | 0.5% | 7589076 linux-image-3.2.0-4-amd64 | 32928159 | 3258 | | 25945856 gzip -9 is always much slower then gzip -6. It is at most 2% better. xz -1 is usualy faster then gzip -9 and much better. However most packages only needs seconds to compress, so the difference will no really matter. So instead of switching to gzip -6, a switch to xz -1 would make more sense in term of size and also speed. So my proposal would be: - Don't do anything for Wheezy. Any change may break the CD creation. - Switch to xz per default for Jessie. xz -3 is often faster in compressing stuff then gzip -9. -6 needs a lot of memory, especially for compressing the files, so reducing the default to -3 may make sense and does not cost much. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, Day of the Dove, stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121110125222.ga16...@waldi.eu.org
Re: Something like nocompress DEB_BUILD_OPTION
On 08/11/12 19:31, Dmitrijs Ledkovs wrote: I would like to have a nocompress Debian build option that will skip any compression/optimisation at build time. That seems like mixing two orthogonal things: an uncompressed or fastest-possible-compression .deb or source package, and speeding up compilation by not optimizing code. Similarly other tools can optionally listen on that variable e.g. skipping pkgmangler and dh_scour. This is mixing in yet more things. dh_scour runs a lossy SVG optimizer (so, it has observable side-effects). pkgbinarymangler is an Ubuntu-specific package which does various things, mostly with observable side-effects, including: * optimize (some) PNGs (losslessly, I assume?) * optimize other files with advancecomp? (losslessly?) * truncate changelogs * strip translations * adjust Maintainer In particular it would be useful during: * change-rebuild-test cycles ... unless your package changes its observable behaviour when not optimized (yes, this does happen, particularly if some C or C++ code has undefined behaviour). * (local) archive rebuilds (when debs are not published, e.g. testing a transition / binNMUs) ... unless one of your packages is miscompiled when (not) optimizing, in which case you can get false positives or negatives in your rebuild. (I've seen this happen too.) If what you want is a DEB_BUILD_OPTIONS option for don't compress source or binary packages, nocompress seems a fine name for that; or to minimize side-effects by preserving the structure of the package, it could be something like quickcompress to keep the packager's choice of gzip or xz but use the fastest possible presets. (It's possible that faster presets don't actually give you more performance if the time to write out the .deb is dominated by I/O, though.) If what you want is a general shortcut option for cut corners to get me a binary sooner, I (am|am not) willing to accept functional changes as a result then it should have a different name, perhaps DEB_BUILD_OPTIONS=quick or something (or two different names, if there are valid uses for both versions). S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/509ccecb.6070...@debian.org
Re: Something like nocompress DEB_BUILD_OPTION
On 9 November 2012 09:37, Simon McVittie s...@debian.org wrote: On 08/11/12 19:31, Dmitrijs Ledkovs wrote: I would like to have a nocompress Debian build option that will skip any compression/optimisation at build time. I am sorry if this was misleading. I am aware of the noopt option and I am aware that disabling compiler optimisations gives you a different (possibly broken) binaries. If what you want is a DEB_BUILD_OPTIONS option for don't compress source or binary packages, nocompress seems a fine name for that; or to minimize side-effects by preserving the structure of the package, it could be something like quickcompress to keep the packager's choice of gzip or xz but use the fastest possible presets. (It's possible that faster presets don't actually give you more performance if the time to write out the .deb is dominated by I/O, though.) This is what I want. And not currently available. True about I/O. Does dpkg-deb writes-out tar to disk before compressing it or is it a pipe? If what you want is a general shortcut option for cut corners to get me a binary sooner, I (am|am not) willing to accept functional changes as a result then it should have a different name, perhaps DEB_BUILD_OPTIONS=quick or something (or two different names, if there are valid uses for both versions). I don't think this one is needed, as noopt + the above nocompress will result in this shortcut, more or less. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujzd7fweq-oervzjqj6uj67f5-cdaxxkdud61ptdjt...@mail.gmail.com
Re: Something like nocompress DEB_BUILD_OPTION
On Thu, Nov 08, 2012 at 04:33:42PM -0800, Russ Allbery wrote: Oh, okay. It would actually be much easier to standardize a way to switch to gzip compression than it would be to add a new concept of uncompressed packages. The problem is: dpkg-deb with gzip is much slower than with bzip2 and xz does not really add much. So you want none in this case. | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.none.deb'. | dpkg-deb -Znone -b debian/linux-image-3.6-trunk-amd64 test.none.deb 0.12s user 1.56s system 108% cpu 1.539 total | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'. | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb 62.96s user 1.78s system 101% cpu 1:03.77 total | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.bzip2.deb'. | dpkg-deb -Zbzip2 -b debian/linux-image-3.6-trunk-amd64 test.bzip2.deb 12.48s user 1.76s system 108% cpu 13.165 total | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.xz.deb'. | dpkg-deb -Zxz -b debian/linux-image-3.6-trunk-amd64 test.xz.deb 103.27s user 2.66s system 101% cpu 1:44.35 total Bastian -- Schshschshchsch. -- The Gorn, Arena, stardate 3046.2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109112619.ga28...@waldi.eu.org
Re: Something like nocompress DEB_BUILD_OPTION
On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote: | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'. | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb 62.96s user 1.78s system 101% cpu 1:03.77 total Some further tests show clearly why this is the case: | gzip -c data.tar /dev/null 6.51s user 0.04s system 99% cpu 6.548 total | gzip -9c data.tar /dev/null 61.46s user 0.08s system 99% cpu 1:01.54 total dpkg-deb defaults to -9 for gzip. This mode takes ten times. This all for an negligible advantage of 1% smaller package. Bastian -- No one may kill a man. Not for any purpose. It cannot be condoned. -- Kirk, Spock's Brain, stardate 5431.6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109145253.ga31...@waldi.eu.org
Re: Something like nocompress DEB_BUILD_OPTION
On 9 November 2012 14:52, Bastian Blank wa...@debian.org wrote: On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote: | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'. | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb 62.96s user 1.78s system 101% cpu 1:03.77 total Some further tests show clearly why this is the case: | gzip -c data.tar /dev/null 6.51s user 0.04s system 99% cpu 6.548 total | gzip -9c data.tar /dev/null 61.46s user 0.08s system 99% cpu 1:01.54 total dpkg-deb defaults to -9 for gzip. This mode takes ten times. This all for an negligible advantage of 1% smaller package. Even without any option it defaults to -6, can you compare -1 as well? Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujlvaexdl5wj16rmgdbq2cmb-duzxshiksu0rbu84-...@mail.gmail.com
Re: Something like nocompress DEB_BUILD_OPTION
Hi! On Fri, 2012-11-09 at 15:52:53 +0100, Bastian Blank wrote: On Fri, Nov 09, 2012 at 12:26:19PM +0100, Bastian Blank wrote: | dpkg-deb: building package `linux-image-3.6-trunk-amd64' in `test.gzip.deb'. | dpkg-deb -Zgzip -b debian/linux-image-3.6-trunk-amd64 test.gzip.deb 62.96s user 1.78s system 101% cpu 1:03.77 total Some further tests show clearly why this is the case: | gzip -c data.tar /dev/null 6.51s user 0.04s system 99% cpu 6.548 total | gzip -9c data.tar /dev/null 61.46s user 0.08s system 99% cpu 1:01.54 total dpkg-deb defaults to -9 for gzip. This mode takes ten times. This all for an negligible advantage of 1% smaller package. There used to be a single global default level (9) for all compressors, which got changed in 2010 to be backend specific, but only xz and lzma were reduced to 6. I don't have any problem with changing gzip (to its upstream default!) if as shown it's a vast improvement speed vs space. I can certainly do that for dpkg 1.17.x, some more numbers would be nice though, as in different types of data.tar, for example, but I would not expect any surprises here, mostly just for reassurance. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109184822.ga32...@gaara.hadrons.org
Re: Something like nocompress DEB_BUILD_OPTION
Hi! On Fri, 2012-11-09 at 10:16:21 +, Dmitrijs Ledkovs wrote: On 9 November 2012 09:37, Simon McVittie s...@debian.org wrote: (It's possible that faster presets don't actually give you more performance if the time to write out the .deb is dominated by I/O, though.) True about I/O. Does dpkg-deb writes-out tar to disk before compressing it or is it a pipe? Oh, it's fairly suboptimal currently. It pipes tar's output to a process compressing it to then write the result to disk, which gets read back and written into the final .deb, for both tar member files. This is pretty bad for big packages. But I already started reworking the code to fix it, so this will be better in dpkg 1.17.x. Similar badness happens on unpack, although at least it does not go through a temp file on disk, also being reworked. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121109190127.gb32...@gaara.hadrons.org
Re: Something like nocompress DEB_BUILD_OPTION
Dmitrijs Ledkovs x...@debian.org writes: I would like to have a nocompress Debian build option that will skip any compression/optimisation at build time. Specifically dpkg-builddeb and dpkg-source should use not use any compression methods. Why do you think this would be of any benefit? gzip compression is pretty fast. It seems unlikely to me that this is a substantial bottleneck. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878vabzmt0@windlord.stanford.edu
Re: Something like nocompress DEB_BUILD_OPTION
On 8 November 2012 23:39, Russ Allbery r...@debian.org wrote: Dmitrijs Ledkovs x...@debian.org writes: I would like to have a nocompress Debian build option that will skip any compression/optimisation at build time. Specifically dpkg-builddeb and dpkg-source should use not use any compression methods. Why do you think this would be of any benefit? gzip compression is pretty fast. It seems unlikely to me that this is a substantial bottleneck. Gzip is ok, but many packages these days use xz -9 --extreme deb options which is not fast at all on my pandaboard nor on my cloud instances with capped CPU memory. Using such compression is good for release debs, but not in developer testing. It wastes developer's time. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluihhtxb1namhtwwpf3ypfyqs__syeqphn+9o3yefjt...@mail.gmail.com
Re: Something like nocompress DEB_BUILD_OPTION
Dmitrijs Ledkovs x...@debian.org writes: Gzip is ok, but many packages these days use xz -9 --extreme deb options which is not fast at all on my pandaboard nor on my cloud instances with capped CPU memory. Using such compression is good for release debs, but not in developer testing. It wastes developer's time. Oh, okay. It would actually be much easier to standardize a way to switch to gzip compression than it would be to add a new concept of uncompressed packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871ug3zkbd@windlord.stanford.edu
Re: Something like nocompress DEB_BUILD_OPTION
On 9 November 2012 00:33, Russ Allbery r...@debian.org wrote: Dmitrijs Ledkovs x...@debian.org writes: Gzip is ok, but many packages these days use xz -9 --extreme deb options which is not fast at all on my pandaboard nor on my cloud instances with capped CPU memory. Using such compression is good for release debs, but not in developer testing. It wastes developer's time. Oh, okay. It would actually be much easier to standardize a way to switch to gzip compression than it would be to add a new concept of uncompressed packages. dpkg-source supports gzip, bzip2, lzma, xz (matters for beefy native packages) dpkg-deb supports none, gzip, bzip2, lzma, xz The reason why I am after a DEB_BUILD_OPTION is that there are multiple tools that can optimized for time. E.g. disable dh_scour that can take also take a while. And setting multiple environment variables is not nice. Alternatively we can abuse the noopt option, but I'd rather not redefine / add extra meaning to the existing options. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluh9yuiqcbcucqymqhf85y+apv1-vrf4va0xwzk5k2b...@mail.gmail.com
Re: Something like nocompress DEB_BUILD_OPTION
On Thu, Nov 08, 2012 at 03:39:55PM -0800, Russ Allbery wrote: Dmitrijs Ledkovs x...@debian.org writes: I would like to have a nocompress Debian build option that will skip any compression/optimisation at build time. Specifically dpkg-builddeb and dpkg-source should use not use any compression methods. Why do you think this would be of any benefit? gzip compression is pretty fast. It seems unlikely to me that this is a substantial bottleneck. Why would you ever use gzip if you have a choice? xz has speed parity with gzip -9 at somewhere between levels 2 and 3, with greatly better compression. Just use xz -0. -- How to squander your resources: those silly Swedes have a sauce named hovmästarsås, the best thing ever to put on cheese, yet they waste it solely on mere salmon. signature.asc Description: Digital signature
Re: Something like nocompress DEB_BUILD_OPTION
On 9 November 2012 00:54, Adam Borowski kilob...@angband.pl wrote: On Thu, Nov 08, 2012 at 03:39:55PM -0800, Russ Allbery wrote: Dmitrijs Ledkovs x...@debian.org writes: I would like to have a nocompress Debian build option that will skip any compression/optimisation at build time. Specifically dpkg-builddeb and dpkg-source should use not use any compression methods. Why do you think this would be of any benefit? gzip compression is pretty fast. It seems unlikely to me that this is a substantial bottleneck. Why would you ever use gzip if you have a choice? xz has speed parity with gzip -9 at somewhere between levels 2 and 3, with greatly better compression. Just use xz -0. Interesting to know. I am after pure speed only, so surely compression `dpkg-deb -Znone` will be the least amount of CPU time for debs. Exact flags can be tweaked, as long as we agree on DEB_BUILD_OPTIONS=nocompress=1 to begin with. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUh+9dEpM+2CnMjug-ZouZsXpYAve8S=gqwdsv6obvn...@mail.gmail.com
