From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D7A6C7EE99 for ; Fri, 10 Jan 2014 18:25:49 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of rdicosmo@gmail.com) identity=pra; client-ip=74.125.82.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rdicosmo@gmail.com"; x-sender="rdicosmo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of rdicosmo@gmail.com designates 74.125.82.179 as permitted sender) identity=mailfrom; client-ip=74.125.82.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rdicosmo@gmail.com"; x-sender="rdicosmo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f179.google.com) identity=helo; client-ip=74.125.82.179; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="rdicosmo@gmail.com"; x-sender="postmaster@mail-we0-f179.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksEAAks0FJKfVKzlGdsb2JhbABZgmpZtEuGWxYOAQEBAQcLCwkSKoIqPAYBOQMNBRcPNAUgAQUBAQ0BLxEBh1UDEQEECJh/gwiPZZFPJw2FIREBBQwKjHiBDSuCeA9mgRMEk3FCg2OBMY54QYFlgnWBaQ X-IPAS-Result: AksEAAks0FJKfVKzlGdsb2JhbABZgmpZtEuGWxYOAQEBAQcLCwkSKoIqPAYBOQMNBRcPNAUgAQUBAQ0BLxEBh1UDEQEECJh/gwiPZZFPJw2FIREBBQwKjHiBDSuCeA9mgRMEk3FCg2OBMY54QYFlgnWBaQ X-IronPort-AV: E=Sophos;i="4.95,639,1384297200"; d="scan'208";a="52723240" Received: from mail-we0-f179.google.com ([74.125.82.179]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 Jan 2014 18:25:49 +0100 Received: by mail-we0-f179.google.com with SMTP id q59so4332952wes.38 for ; Fri, 10 Jan 2014 09:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=Sqyr9iQOufafRKmPZy6XyQuTFVxuUM44VL17qGYTi8Q=; b=fD85cUrIfCXOSz0ZJNsop88RTcnab3IpHk0uavCk4xmurO6EzQd+O5laaqFnbF5lt3 OFXO0GNqn73jEOTO/OzsocnYVwnHoHDwSGsH+8TfxLc0jagLO8JtuFIIEYf2lHlzped7 1UaE6efnC6hJFIenFrnJGbQLffzPtVLo/UBrX8ESgkCLPWL0R7mGImu8OT/0oJ/xnLRT MapLK7OVBrzpMzMm2xFzHkCwKvY1JH+lQA6NYvNw64P6jkdxd27tJX70x1zh8eA0E/IR p8YDgeeN1s9PvnuQWARZynKB9suzAOC4/vFXbupjoZQ+o9t1soTYZIFC3GjZPjOz0Mzk pM8Q== X-Received: by 10.180.187.72 with SMTP id fq8mr3816831wic.26.1389374749119; Fri, 10 Jan 2014 09:25:49 -0800 (PST) Received: from voyager ([2001:660:3013:3:5e26:aff:fe33:808f]) by mx.google.com with ESMTPSA id mv9sm3591840wic.1.2014.01.10.09.25.47 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 10 Jan 2014 09:25:48 -0800 (PST) Sender: Roberto Di Cosmo Received: from dicosmo by voyager with local (Exim 4.80) (envelope-from ) id 1W1fq7-0005Xl-53 for caml-list@inria.fr; Fri, 10 Jan 2014 18:25:47 +0100 Date: Fri, 10 Jan 2014 18:25:47 +0100 From: Roberto Di Cosmo To: caml-list@inria.fr Message-ID: <20140110172547.GA20742@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Caml-list] External dependency solvers for opam Dear all, the short story is that we need help in packaging for Mac OSX and Windows some specialised solvers that can be used with opam, and are already packaged for Debian: aspcud, mccs and packup, with aspcud being the highest priority. The Debian packages, built by Ralf Treinen, are a good entry point for any volunteer, as they contain the pointer to the upstream source, list the C/C++ libraries and other dependencies involved, and contain useful patches not yet integrated upstream; even if you do not have a Debian (or Ubuntu) machine at hand, most of the information is available here aspcud : http://packages.debian.org/wheezy/aspcud mccs : http://packages.debian.org/wheezy/mccs packup : http://packages.debian.org/wheezy/packup If you are willing to help with this work, please post a comment under the corresponding issues opened on github, and say to what part of the effort you whish to contribute, so we can have some basic coordination among the volunteers. aspcud : https://github.com/ocaml/opam/issues/1074 mccs : https://github.com/ocaml/opam/issues/1075 packup : https://github.com/ocaml/opam/issues/1076 Now, here comes the long story, that might be of interest for you even if you are just a regular user of opam. As you might know, the opam package manager incorporates state-of-the-art technology that has been developed for managing packages in GNU/Linux distributions in the Mancoosi project (www.mancoosi.org), and uses the libcudf and dose libraries from it. A key point of the approach which we set forth in Mancoosi (for the interested reader, see [1,2] below), is that a modern package manager should clearly separate a platform specific front-end from a platform independent back-end in charge of solving dependencies in order to perform upgrades or downgrades according to the user's preferences. Using the CUDF format as a pivot, we can share the effort of developing efficient solvers among multiple package managers, and can even use different solvers in the same package manager if the default one hits its limits (which *can* happen, as dependency solving is an NP-complete problem). This is actually possible today in Debian: you can call apt-get with the option --solver SOLVER where SOLVER can be aspcud, mccs or packup. User preferences are an important, and often overlooked concept: when you request the installation of a package, there might be many ways of satisfying it, and a user should be able to state, for example, whether he is a "trendy" person that prefers to see all other packages upgraded to the latest possible version at the same time, or on the contrary, a "paranoid" person that wants to change them as little as possible. This is why all CUDF compliant solvers allow to specify user preferences by combining lexicographically keyworks like "new", "changed", "removed", "notuptodate"; for example, a trendy person will use as preference -removed,-notuptodate,-new meaning "please minimise the number of removed packages, and then the number of packages that are not at their latest version, and finally the number of package that were not already present" While a paranoid person would use -removed, -changed meaning "please minimise the number of removed packages, and then the number of packages that are modified (installed/removed/upgraded/downgraded)". Actually, the criteria supported by the CUDF solvers evolved over time, and aspcud supports nowadays a more sophisticated preference language (see http://www.mancoosi.org/misc-2012/criteria/), but all of "new", "changed", "removed" and "notuptodate" can be encoded in the latest version, and aspcud as packaged for Debian accepts them right away. The good news is that opam has built-in support to use aspcud as an external CUDF-compliant solver too: if aspcud is installed on your machine, then dependency solving will be delegated to aspcud, and the default preferences are set to -removed,-notuptodate,-new. You can change these preferences if needed by just setting the OPAMCRITERIA environment variable, and you can ask opam not to use the external solver with the option --no-aspcud (that should really be --no-external-solver). Now that the opam users are hitting the limits of the internal solver embedded in opam, it is important to have CUDF compliant solvers available on all platforms: aspcud is a priority because it can be used by opam right away (no need to change even a single line of code), but packup and mccs are important too, as with little changes in the opam code one will be able to choose which solver to use. So, to sum up: - if you are running Debian (or a Debian-based distribution, like Ubuntu), lucky you, just apt-get install aspcud and you are all set; you can even play with OPAMCRITERIA to adjust the solutions to your needs, and you can use --no-aspcud if you want to see the difference with the internal solver - if you are on another platform, stay tuned for when packages for aspcud/packup/mccs will be available on your platform -- Roberto [1] A modular package manager architecture, http://dx.doi.org/10.1016/j.infsof.2012.09.002 also freely available from http://www.dicosmo.org/Articles/2013-AbateDiCosmoTreinenZacchiroli-Ist.pdf [2] Dependency solving: A separate concern in component evolution management, http://dx.doi.org/10.1016/j.jss.2012.02.018 also freely available from http://www.dicosmo.org/Articles/2012-AbateDiCosmoTreinenZacchiroli-Jss.pdf