On Tue Nov 18 2014 at 11:09:15 PM Michael Tokarev <[email protected]> wrote:
> This is sort of insane - using dpkg-dev just to get current > architecture. dpkg-dev pulls in binutils, some perl stuff, > patch, others -- 27 extra megabytes. I use it on systems > with a highly space-constrained flash-based storage If you are really space constrained I can't get why you are using eatmydata and not the libeatmydata1 library directly. > dpkg --print-architecture. But I really wonder: _why_ it uses that? What dpkg --print-arch > gives us? I can install foreign dpkg, or run foreign binaries > whose architecture has nothing to do at all with the one of > dpkg. What's the reason to ask current architecture of dpkg > to start with? > At that time I didn't want to completely drop the path in the LD_PRELOAD variable, and a call to dpkg was the only way I could think on how to get it. Anyway, don't worry. It will go away in the two next uploads.
