Sughosha <[email protected]> writes: > I was thinking of reducing the closure size of Guix in general. I am inspired > by > Alpine Linux for having dev and doc outputs (I am not sure if they call them > "outputs", I was using Alpine Linux some years ago).
The term Alpine uses is "sub packages". > So, I think if we can make at least "dev" output as one of the > defaults (just now only "out" exists as the default), we would be able > to move a huge number of packages from inputs to native-inputs, having > a great reduction in the closure size. If we would be doing this I think interesting candidates for default outputs are: out doc - Info manuals, man pages dev - pkg-config files, headers, ... dbg - Debug symbols Separating debug symbols by default is possibly worth considering even if the -doc and -dev will not happen, since the impact on pack size could be significant. And it should not suffer from the problem Andreas mentioned regarding complicating package definitions. Andreas Enge <[email protected]> writes: > I am not a big fan; one advantage that I see in Guix over Debian is that > when I install a C library, I immediately can work with it in a > development context. Just "gmp", not "libgmp" and "libgmp-devel". > And there would be a lot of duplication in defining packages: > When now we have gmp as an input, we then would need gmp:out as an input > and gmp:dev as a native-input. I see your point, especially regarding the duplication in package definitions. I think relevant aspect is how much it cuts down closure sizes. If my ~500 MB pack I need at work goes down by 10%, 20% percent, it would be interesting, if this shaves few hundred kilobytes it is probably not worth the hassle. I do see some appeal in the proposal, because I rarely need info manuals in packs, and conversely I install some packages into my home profile *just* to get the info manuals and man pages. Though, now that I think about it, both these cases could be well addressed by some transformation procedure (that I need to write)... Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
