IRC channel logs


back to list of logs

<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
<nextos6>or git will install subversion
<nextos6>which i find a bit suboptimal
<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>thats what i dont get
<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.
<davexunit>downloading binaries is an optimization.
<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
<nextos6>guix sorry
<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
<nextos6>yes, i know, and that's great
<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.
<nextos6>aha, i see
<nextos6>it's more of a resources issue
<nextos6>in some constrained devices
<nextos6>HD mostly
<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 about it and see what people besides me think.
<nextos6>ok, thanks for your time!
<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>mark_weaver: i know
<nextos6>i was trying to argue that perhaps one should distinguish
<nextos6>compile time and runtime dependencies
<mark_weaver>we already do
<nextos6>oh, ok, im very ignorant wrt guix/nix
<mark_weaver>if you look at a package build on, 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>yes, that i know
<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>yes, and git
<nextos6>and some others
<nextos6>actually im in the situation where slack or arch
<nextos6>only take a fraction of what my nix install does
<nextos6>which actually fills in the disk
<nextos6>with the same package selection
<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.
<mark_weaver>so that might be part of the reason.
<mark_weaver>it would require some investigation
<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!
<nextos6>i know, that's a major issue to
<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.
<nextos6>so i'd like to stick to binaries!
<nextos6>gotta run now, super late here
<mark_weaver>okay, good night!
<nextos6>good night, all the best
***mattl_ is now known as mattl
***JamesJRH_ is now known as JamesJRH
<civodul>Hello Guix!
***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>Ah so you did.
<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>that should be somewhat visible ;-)
*civodul managed to bork the GnuTLS fix, grr
<civodul>will push a fix of the fix RSN
<jgay_>civodul, I hang out here, too
<civodul>ok, GnuTLS fix fixed
<civodul>now to bed, ttyl!
<mark_weaver>oh bummer about the gnutls fix :-(