Hi Maxim, Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
> Ludovic Courtès <l...@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’.
