l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Hartmut Goebel <h.goe...@crazy-compilers.com> skribis:
>> I'm in favor of (automatically?) splitting of "development" packages, >> including the headers and the static libs (much like the "-devel" or >> "-dev" packages in other distributions. One does not need them on a >> production system and they are just wasting space. When Guix needs to >> build a package, it automatically installs the ":devel" output of all >> it's inputs. I've been arguing for making sub-packages similar to other distributions, but I'd expect to specify something like :devel as the input to builds. I'm not sure that it would even work generally to infer it (e.g. when cross-compiling). > We could do that (the Nixpkgs folks did exactly that a while back), but > it won’t help that much. It looks to me as if it would often help significantly, e.g. when a pkg-config file, or something else sucks in a load of stuff that's irrelevant for running the package. (Separating :lib and needing that for building means you need to know something about the packaging rather than just using "devel", say.) > What does help is running ‘guix size’, looking > at specific packages that are problematic, then finding a solution for > these packages—and often enough the solution is non-trivial. I think it often will reflect the lack of separation of development files, documentation, etc., and inclusion of static libraries, for instance. Boost is a case in point. There's also the issue of multiple copies/versions of packages in the closure, which seems problematic for more than just size reasons. > But yeah, I think we should track packages that are big or have a > surprisingly build closure, and try to fix that incrementally! Shouldn't that be done as a matter of course? I don't remember if it's part of Fedora or Debian packaging guidelines but packagers should check dependencies for sanity when packaging, and there's some detection of unnecessary linkage. Guix' Qt dependencies are a striking example which looks hard to resolve. Generally I get surprised at what typically gets built -- at great length! -- on updates or installation.