bug#61853: ‘guix pack’ shell tests fail

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> That’s an acceptable change IMO, introduced in
>> 68380db4c40a2ee1156349a87254fd7b1f1a52d5.  However, the tests were
>> evidently not run after that change, which is problematic.
>
> Interesting.  I had done all my testing using tests/pack.scm (and the
> new tests/rpm.scm), and overlooked tests/pack.sh.

…

>> Anyway, fixed in 92a0e60a963a54230e400c5c2ae585205489bf35.  Both tests
>> now pass for me.
>
> Thanks (again)!

To be clear, it’s time-consuming and stressful.  That’s not sane and I’d
rather not work that way.

>> One issue with 68380db4c40a2ee1156349a87254fd7b1f1a52d5, though, is that
>> it introduces a copy of the profile being built to the store
>> (“profile-directory”).  This was purposefully avoided before because
>> it’s very I/O-intensive, space-consuming, and puts more pressure on the
>> store.  It’s a pattern we avoided for system images too, having noticed
>> its cost (commit 7f75a7ec08975eb6d6e01db61bd6b91f447f655e for instance.)
>>
>> We may need to come back to a single derivation well or creating packs
>> for big profiles will be too costly.
>
> I agree it's expensive; we're trading IO for storage though, so the case
> of generating the same pack in multiple format, it could be beneficial
> by only computing the union directory once.  The real motivation was
> avoiding code duplication though; perhaps this could be accomplished by
> moving the common logic to (guix build pack-utils)?

Yes, that’s a good idea.  There’s already (guix build pack) and I guess
we could move roughly the contents of ‘self-contained-tarball/builder’
and ‘populate-profile-root’ there.

How does that sound?

Thanks,
Ludo’.