Hi,

On Tue, 2008-04-01 at 14:11:37 +0100, Neil Williams wrote:
> Just my 2p, from an embedded angle, it would be very useful if all the
> lzma options can be turned off (cleanly and reproducibly) when
> rebuilding / crossbuilding the package because if lzma is used too
> widely it could easily overwhelm embedded devices with limited memory.

This kind of policy, which packages can/should/whatever use non-gzip
compression methods is outside the scope of dpkg, this one only
provides the functionality.

> Ideally, something in DEB_BUILD_OPTIONS would be very helpful, which
> means allowing debian/rules complete control over whether lzma is used
> or not and all consequent changes. Then a simple check for 'nolzma' in
> DEB_BUILD_OPTIONS can turn off all the lzma features and revert to gzip.

Packages could standardize on a DEB_BUILD_OPTIONS string to disable
non-gzip compression when calling dpkg-deb (directly or indirectly via
stuff like dh_builddeb). Again, this is outside the realms of dpkg.

> The Ubuntu page also talks about using lzma for the Packages file in
> repositories to save download time - the risk of making it impossible
> for low memory devices to actually then unpack the Packages file worries
> me a lot so a duplicate file is probably best for that (but is off-topic
> for this bug).

We already have bziped Packages files, but the gzip ones are still
available, I don't see them disappearing once and if lzma ones get
generated. The one to be used is a client-side decision.

Also on really embedded systems you might prefer trimming down the
Packages files anyway, either of useless fields or package entries. The
current sid Packages file is 23 MiB uncompressed!

> It would be a shame to fix important cross-building bugs in one release
> and then undermine using dpkg on devices that require crossbuilt
> packages in the next.

I don't see how those are related. dpkg does not dictate who is going
to use this stuff.

regards,
guillem



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to