Re: Something like nocompress DEB_BUILD_OPTION
- To: email@example.com
- Subject: Re: Something like nocompress DEB_BUILD_OPTION
- From: Simon McVittie <firstname.lastname@example.org>
- Date: Fri, 09 Nov 2012 09:37:15 +0000
- Message-id: <509CCECB.email@example.com>
- In-reply-to: <CANBHLUj_Td_jpUUTe37hvbUbZNWKa+vgwpCVY31_Xr39bYWHfirstname.lastname@example.org>
- References: <CANBHLUj_Td_jpUUTe37hvbUbZNWKa+vgwpCVY31_Xr39bYWHemail@example.com>
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
> * (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).