From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Multiple versions Date: Sun, 27 Dec 2015 13:28:47 +0100 Message-ID: <87si2o3wjk.fsf@elephly.net> References: <20151227052600.GA32379@thebird.nl> <20151227092027.GA1958@sagulo> <20151227094832.GA6452@debian.fritz.box> <20151227104109.GA11215@sagulo> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDARX-0005BU-5m for guix-devel@gnu.org; Sun, 27 Dec 2015 07:29:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDARW-0007Ec-Ac for guix-devel@gnu.org; Sun, 27 Dec 2015 07:28:59 -0500 In-reply-to: <20151227104109.GA11215@sagulo> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Dmitry Bogatov Cc: guix-devel@gnu.org Dmitry Bogatov writes: >> Then there is the combinatorial explosion. If you have 20 libraries in >> 10 versions each that are needed to build a derived binary, then there >> will be 10^20 possible combinations. Which of them would you like to >> support? > > Build binaries with latest versions of libraries and compilers. > >> Our general policy is to keep only the latest version, except for special >> cases where people see a point in keeping older versions (script languages, >> libraries like qt with two major versions supported in parallel, and so on). > >> What is your use case? If you want reproducibility, it could make sense >> to simply stick to a given git commit. If you just need a particular older > > My use case is that I want to be able to install every version of > any haskell library and every version of ghc for testing purposes. > > For example, I write code, that uses ghc-7.10 with lens-4.13. Will it > work with ghc-7.6(Debian stable) and lens-4.1.2.1? This versions are > important to me, but some other person may have another reference. This doesn’t seem to be a useful way for the Guix project as such to use our limited resources. However, Guix is a library and packages are just Scheme values. You can write a procedure that recursively replaces the GHC value throughout the graph of a given package. Then you can build variants of the package graph that use a different version of GHC. > Yes, there is combinatorics, but not too terrible. ~1000 packages, 4 ghc > versions -> 4000 variables. This is only for different versions of GHC, but not different versions of packages such as lens. > Ah, and I do not propose to actually support, for example, > ghc7.6-lens-4.13. If it fails to build, that it is dropped. Then it may be better to do this on a machine dedicated to the task of testing Haskell package combinations. > Some kind of automatization and integration with hydra would > be useful. Using our main Hydra instance for this seems like wasting resources that could be used for other purposes more closely related to the goals of the Guix project. ~~ Ricardo