<py1hon>if you just want to point at a specific version, you can just point it at a specific revision (which is what i was planning on doing anyways)
<mark_weaver>well, civodul is the main architect of guix so far, and I'm not sure of his exact reasoning, but for one thing building from git usually requires more prerequisite packages, and often very specific versions of those packages, e.g. autoconf, automake, documentation builders, etc.
<py1hon>oh - well, that's just autoconf brokenness
<py1hon>anyways - if i want to package, say, bcache-tools for guix - suppose you could tell me where to get started?
<mark_weaver>I'm not sure I agree with that. there are significant costs to maintaining perfect compatibility, and advantages to allowing some flexibility in evolving. for example, linux (the kernel) has benefitted enormously from refusing to maintain compatibility in its internal interfaces (used by device drivers, for example).
<mark_weaver>py1hon: I'd start by looking over the pdf file I cited.
<py1hon>that's not exactly the type of brokenness i meant, but no worries :P
<mark_weaver>if you want to contribute your own packages, you should run guix out of a git checkout, so that means using "git pull" and "make", not "guix pull".
<py1hon>ok, knowing where to find all the existing packages will help greatly
<py1hon>guix pull giving you the latest tagged release, i take it?
<mark_weaver>and then using "./pre-inst-env guix ..." so you use the copy of guix in the git checkout as opposed to the "installed" version. in fact, there's no need to do "make install" at all in this mode.
<mark_weaver>the existing packages are all in gnu/packages/*.scm in the git checkout.