Re: Tiny Guix (and containers)

[Ludovic Courtès]

Dave Love <address@hidden> skribis:

> Pjotr Prins <address@hidden> writes:
>
>> But, really, I think when talking embedded systems and containers we
>> all want tiny. Even HPC can benefit. Tiny containers may be an
>> attractive proposition.
>
> Yes, containers aside, dependencies in Guix are one of the reasons I'm
> currently unconvinced by its trades-off for HPC use; the closure a
> single package can be comparable with the whole compute node image I
> used to maintain with rpm.  Even then, you don't generally have
> debugging info available.
>
> I suppose the general point is that Guix seems to have rejected
> experience from other distributions, and it's not clear to me why.  (I
> don't mean it should necessarily follow them, of course.)  Is there any
> summary of the rationale for different decisions like not splitting
> packages into development and runtime and other components, packaging
> static libraries, and discarding debugging information, for instance?

The main reason, as you have noticed, is that multiple outputs don’t
always work out-of-the-box: the GC scanner does not handle circular
dependencies among outputs of a given derivation, which makes things
more difficult.

Another reason is that splitting is just part of the story.  Often, it’s
not moving out 10 KB of header files that really helps; rather, it’s
stripping the dependency graph.

Some people also argued that having everything in one package made
things easier for them as users, though that one is more questionable to
me.

Ludo’.