<zacts>someone should port musl-libc to guix <zacts>it would be interesting to provide musl as an option for an alternative C library <zacts>especially for the embedded platforms <zacts>I'm currently too busy to help with this *davexunit tries to package guile-sdl for the third time <davexunit>still just as hard as I remember. the guile-sdl build system is insane. <nextos6>hello, what's guix policy wrt optional runtime dependencies <nextos6>im asking cause i think this is a shortcoming of nix <nextos6>e.g. installing mutt will bring in python <davexunit>nextos6: we typically include every optional dependency that makes sense in order to have a fully featured package. of course, you can easily change such things for your own builds. <nextos6>davexunit: but how does this compare to typical distros like debian or arch <nextos6>in these you can install things optionally without rebuilding packages <davexunit>certainly not configure-time optional dependencies? <davexunit>anyway, guix and nix are purely functional. the same software with different optional dependencies added are different builds. <nextos6>why runtime optional deps influence purity <davexunit>those dependencies are often checked in the configure script and are required for building the source. <davexunit>thus they are an explicit part of the package build. <nextos6>i know, but i've been using nix a bit and its certainly a bit <nextos6>ugly to install mutt and get a truckload of deps, like python <nextos6>and i dont see how purity is related to optional dependencies, but i might be completely wrong <nextos6>also if you try to keep your packages lean, the burden of maintainance is enormous <nextos6>essentially you have to edit all packages, as they have everything by default <davexunit>the reason that they effect purity is because the presence/absence of them affects the build. we are after reproducible builds. <davexunit>in certain cases, we build packages sans some dependencies. for instance we have an emacs package that is built without X support. <davexunit>also, keep in mind that guix/nix are primarily source-based distributions. <nextos6>i see, i'm in a very modest piece of hardware, so binaries are a must <nextos6>and they are dealt with nicely in nix, i guess its the same in nix <davexunit>so there's no separation between the user and the remote package repo. <davexunit>there's no maintainer that builds the package with all the flags turned on, and then distributes that to users who can then choose the optional stuff. <nextos6>but turning it off means recompiling right? <davexunit>while I think that is convenient, it doesn't fit the model of reproducibility and purity. <davexunit>maybe there's a clever way around this, but I don't know it. <davexunit>I can certainly empathize with the desire for leaner packages. <nextos6>yes, if guix was like arch it'd be ideal <davexunit>it's a trade-off, arch doesn't make the guarantees that we make. <nextos6>if you regard optional dependencies as dynamically linked, i don't see how builds would be different <davexunit>guix packages refer *directly* to those dynamically linked libraries <davexunit>as in, an absolute path, not whatever happens to be installed. <nextos6>yes, but why not referring to them, no matter whether they are installed or not <nextos6>i know you're referring to a particular directory with a hash that guarantees exact dependencies <davexunit>keep in mind that installing mutt with a python dependency won't pollute *your* package profile with python if it's not a propagated input, which most inputs aren't. <davexunit>it will be on the system, but mostly invisible to you. <davexunit>perhaps we could host 'lean' versions of packages with lots of optional dependencies, but then it's the question of which permutations of those dependencies we provide. <nextos6>yes, youre right in the sense that its a combinatorial problem <davexunit>nextos6: I've gotta go afk now. maybe there's some way to accomodate what you want. try sending mail to guix-devel@gnu.org about it and see what people besides me think. <mark_weaver>damn, gnutls-3.2.19 failed its test suite on my yeeloong. just keeping the mips regressions under control is taking more time than I'd like. <mark_weaver>nextos6: there's no technical reason why we couldn't support more customizability of dependencies, like gentoo's use flags, but if we did that, the number of possible build combinations would by multiplied by a large factor, so it's unlikely that our modest build farm would be able to handle all of the combinations, so users would have to build everything on their own box. <nextos6>i was trying to argue that perhaps one should distinguish <nextos6>compile time and runtime dependencies <nextos6>oh, ok, im very ignorant wrt guix/nix <mark_weaver>if you look at a package build on hydra.gnu.org, there are separate tabs for build dependencies vs runtime dependencies. <mark_weaver>build dependencies are always a superset of the runtime deps. <mark_weaver>build deps are the packages that are made available in the chroot where the builds happen <mark_weaver>runtime deps are the references that are found in the build outputs <mark_weaver>since every reference to another package in our outputs includes the long hash string, we scan every file of the build output looking for those hashes. <nextos6>i was kind of asking whether it'd be possible to <nextos6>make some runtime dependencies optional, without rebuilding the package <mark_weaver>in my experience, very few packages support that kind of optional runtime dependency. usually, there's a decision made at build time. <nextos6>mark_weaver: well, in the cases i was pointing to they do support it <mark_weaver>but emacs is one such example. it looks for various executables in your PATH, and can often cope with their absense. and our emacs package does this. <nextos6>actually im in the situation where slack or arch <nextos6>only take a fraction of what my nix install does <mark_weaver>I don't know much about slack or arch, but debian (and derivatives) tend to break each source package up into multiple output packages. for example, libraries tend to have separate *-dev packages. <mark_weaver>guix can do this too, but so far we haven't taken as much advantage of this ability as maybe we should. <nextos6>oh, ok. Ill post a more detailed question to the mailing list <mark_weaver>also, if you build packages from source code, then you need all of the compilers and other build dependencies, which aren't needed if you simply download binaries (which we support) <nextos6>thanks for taking the time to teach me some guix! <mark_weaver>sure. civodul is the real expert on guix (and nix), so he can probably give some insight if you post on the ML. ***mattl_ is now known as mattl
***JamesJRH_ is now known as JamesJRH
***DusXMT_ is now known as DusXMT
<jmd>So when is the next release, and what goes into it? <civodul>i emailed half an hour ago on that topic :-) <civodul>seems like we both have the feeling that time has come ;-) <jmd>It looks like most of the changes since the last release are things not user visible. <civodul>well there's OS things like swap + device mapping, the Emacs UI, 'guix environment', 'guix lint' *civodul managed to bork the GnuTLS fix, grr <jgay_>civodul, I hang out here, too