Re: [lmi] Creating a chroot for cross-building lmi

[Greg Chicares]

On 2020-05-17 16:34, Vadim Zeitlin wrote:
> On Sat, 16 May 2020 22:03:21 +0000 Greg Chicares <address@hidden> wrote:

[...debootstrap --cache-dir...]

> GC> ...so '--cache-dir' matters greatly.
> 
>  It certainly helps, but I find that creating the new chroot without the
> cache in 2 minutes is already pretty fast. I.e. use of the cache reduces
> the time by almost 50%, but it's still less than 50s, so it's not a huge
> deal.

One minute saved out of twenty-three is about four percent: not
enormous. It's probably less significant for a faster internet
connection. But it can be important if a remote server is flaky.

> GC> Vadim--Given that /var/cache/apt/archives/ and the above /tmp/sidcache/ 
> are
> GC> just collections of '.deb' files, is there any good reason to keep them
> GC> separate?
> 
>  I must admit I'm puzzled by this question. I'd like to turn it around:
> what good reasons do you have to merge them?

Centos has...
  /var/
    cache/
      yum/
        x86_64/
          7/
            base/
            centos-sclo-rh/
            centos-sclo-sclo/
            epel/
            extras/
            updates/
but the '.rpm' names in those subdirectories are all distinct;
and they're mostly either '.x86_64.rpm' or 'noarch.rpm', so I
don't see any advantage to the /x86_64/ subdirectory especially.

That gave me the idea of doing the exact opposite: saving all
'.deb' files in a single directory.

> GC> It would seem simpler to throw all those '.deb' files into a
> GC> single location. Certainly apt already knows which of these to use for
> GC> my 'buster' base system:
> GC>   /var/cache/apt/archives/base-files_10.3+deb10u1_amd64.deb
> GC>   /var/cache/apt/archives/base-files_10.3+deb10u2_amd64.deb
> GC>   /var/cache/apt/archives/base-files_10.3+deb10u3_amd64.deb
> GC>   /var/cache/apt/archives/base-files_10.3+deb10u4_amd64.deb
> GC> so would it do any harm if I moved this 'bullseye' file:
> GC>   /var/cache/bullseye/base-files_11_amd64.deb
> GC> into the same directory?
> 
>  I don't think so, there should never be any conflict between the package
> names from different distributions.
> 
>  But I still don't know why would you want to mix and match them like this,
> instead of using separate directories for them. I admit I don't have any
> good explanation for my gut feeling of wrongness of doing it,

My rationale is that I have a gut feeling that it would be righteous.

But that's all subjective. What I already have certainly works,
and changing it would take effort, so I won't change it.

> the only
> thing I can think of is that if you run "apt clean" in either the main
> system or chroot this will remove all files, not just the ones for the
> current system, but I guess you could just never run "apt clean"...

I wasn't even aware that such a command as 'apt clean' existed.
But I guess your system dates back to the early days of debian,
so you've had time to accumulate many versions of packages; and
you really wouldn't want to restore the "potato" version of 'bash'.

> On Sun, 17 May 2020 15:40:04 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> '--variant=minbase' does have some benefit: for example, it
> GC> excludes cron, fdisk, and nano, none of which are really
> GC> needed in a chroot.
> 
>  This is nice, but AFAICS it excludes all the packages with the priority of
> "important", which also includes things like less and readline, that I
> definitely want to have on any interactive system, and also more or less
> everything network-related (iproute2, iptables, netbase), but also procps
> and udev which might be expected to exist by a number of programs. I'm not
> sure I like the odds of having to track down some weird problems in the
> future just because some of the almost-always-available system components
> turns out not to be there.

OTOH, I've already discovered that 'less' isn't included in a basic
centos installation, so I had to add that specifically. I'll experiment
with this debian "minbase" to see whether I'm really missing much.
So far, the only missing program I've found is 'mt', which autoconf
seems always to check for, even though magnetic tapes went out of
fashion a long time ago:

---default
+++minbase
 checking for x86_64-w64-mingw32-mt... no
-checking for mt... mt
-checking if mt is a manifest tool... no
+checking for mt... no
+checking if : is a manifest tool... no
 checking for ANSI C header files... yes

[I wonder why "mt" got changed to ":" on the last differing line,
but I'm not curious enough to research that.]

> GC> Incidentally:
> GC>   time some_command 2>&1 |less
> GC> gives only the total time, including time spent in 'less', so
> GC> it's not very useful;
> 
>  I don't know why, but I don't see this here:
> 
>       % time echo foo | less
>       foo
>       echo foo  0.00s user 0.01s system 78% cpu 0.009 total
>       less  0.00s user 0.00s system 9% cpu 0.043 total
>       % time sleep 1 | less
>       sleep 1  0.00s user 0.01s system 0% cpu 1.028 total
>       less  0.00s user 0.00s system 0% cpu 1.026 total
> 
> i.e. I do get time for both commands.

Wow, same here. I guess I've been getting the statistics I wanted
all these years, without realizing it.

>  If I really wanted to measure just the time of a single pipeline
> component, I'd do this:
> 
>       % {time sleep 1}|less
>       sleep 1  0.00s user 0.01s system 0% cpu 1.015 total

Fascinating. 'time' seems fairly magical, and it never occurred
to me that it could be scoped within an inline-group. Thanks.