On Tue, Oct 06, 2015 at 06:59:44PM +0200, Konrad Hinsen wrote: > Here's an example (a simplified version of the real situation that motivated > me to check out Guix): > > - I need to use Program X that depends on libraries A and B. > - The current versions are A-1.1 and B-42.0.1. > - X requires "1.0 or later" for A but "41.*" for B, because > version 42.* of B is not fully backwards compatible. > > If there's no Guix commit that has both A and B in the required > version range, then the easiest way to get what I need is to use an > older Guix commit for installing B than I use for A. > > In fact, the only other alternative I see is to add a package definition > for the old version of B to a later Guix commit. That's likely to be > much more difficult.
Create multiple packages. Such as we do for Ruby 1.8, 2.1 and 2.2. You can specify specific dependencies on each using one git checkout. > > Note that you can also tar ball a binary package with all its > > dependencies (using guix archive) and distribute that. That is > > reproducible at the binary level. That may be more useful for end-users. > > That's what I would use to share environments with collaborators. But > I wouldn't download binaries from a stranger, and I don't expect > others to have a different attitude. Agree. But sometimes convenience wins. Also the binary tar balls may help with rapid deployment. Pj.
