From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Tiny Guix (and containers) Date: Sun, 05 Nov 2017 17:02:34 +0100 Message-ID: <87o9ogr9wl.fsf@gnu.org> References: <20171025081846.GA28005@thebird.nl> <87mv4emlwf.fsf@elephly.net> <20171026104259.GA2179@thebird.nl> <87r2tn3ulq.fsf@gnu.org> <878tfr7667.fsf@albion.it.manchester.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBNNj-0001Uq-4x for guix-devel@gnu.org; Sun, 05 Nov 2017 11:02:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBNNh-0007fX-UH for guix-devel@gnu.org; Sun, 05 Nov 2017 11:02:43 -0500 In-Reply-To: <878tfr7667.fsf@albion.it.manchester.ac.uk> (Dave Love's message of "Tue, 31 Oct 2017 14:17:36 +0000") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Dave Love Cc: guix-devel@gnu.org Heya, Dave Love skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Hi, >> >> Hartmut Goebel 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). OK. >> We could do that (the Nixpkgs folks did exactly that a while back), but >> it won=E2=80=99t 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.) Right, good point. The nice thing with =E2=80=9Clib=E2=80=9D and =E2=80=9Cdoc=E2=80=9D is that= it has a direct mapping to the GNU directory classification (libdir, docdir, etc.) Now, we could depart from it and go with =E2=80=9Cdevel=E2=80=9D, for the r= easons you give. Let=E2=80=99s experiment and see how it goes! >> What does help is running =E2=80=98guix size=E2=80=99, looking >> at specific packages that are problematic, then finding a solution for >> these packages=E2=80=94and 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. Boost is also a special case, being a mostly-header library. :-) But yeah, I get your point. >> 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. No argument here! The guidelines at also mention the closure size. We can clearly do better though, and what you=E2=80=99ve been doing with Open=C2=A0MPI et al. is a step in the right direction IMO. I would very much welcome experiments introducing =E2=80=9Cdevel=E2=80=9D o= utputs. Perhaps as a first step we could make it opt-in. We would add support for that in gnu-build-system.scm, and then modify key packages to use =E2=80=9Cdevel=E2=80=9D instead of =E2=80=9Clib=E2=80=9D, for example. Inc= remental changes like this can be tractable. Thoughts? Ludo=E2=80=99.