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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id A2FF27EC41 for ; Mon, 22 Oct 2012 17:17:06 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8BAG1ihVBZELGagWdsb2JhbABFrweSLQEBFiYngiABAQQBOjQLBQsLJSFFEgYTEodgAwkKB7IHA4lehXWFaoYPYAOIWo0XgReSLw X-IronPort-AV: E=Sophos;i="4.80,630,1344204000"; d="scan'208";a="159948643" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail4-smtp-sop.national.inria.fr with SMTP; 22 Oct 2012 17:17:05 +0200 Received: (qmail 2046 invoked by uid 634); 22 Oct 2012 15:17:04 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from 94.sub-70-196-10.myvzw.com (HELO [192.168.1.118]) (70.196.10.94) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Mon, 22 Oct 2012 16:17:03 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Anil Madhavapeddy In-Reply-To: <50854D34.4000301@eu.citrix.com> Date: Mon, 22 Oct 2012 10:16:59 -0500 Cc: Content-Transfer-Encoding: quoted-printable Message-Id: <8226B67D-CCE7-4029-B5B4-FE636941EB40@recoil.org> References: <50854D34.4000301@eu.citrix.com> To: Jon Ludlam X-Mailer: Apple Mail (2.1498) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] opam and versions Hi Jon, I ran into exactly this problem with Mirage, and have solved it for now by = having two separate OPAM remotes for the stable and development systems. A= continuous build system (Jenkins) installs all packages with and without t= he development remote, and highlights any dependencies that have crept in o= n every push. I would like the ability to specify remote refs/tags/branches too, as Gabri= el suggests. This is worth a feature request at http://github.com/OCamlPro/= opam, preferably with an intended workflow of what you'd like. For the purposes of reproducible builds, you may find that 'opam-mk-repo' c= omes in useful on a checkout out package repository. It populates the archi= ves/ directory of a repository with a tarball containing the exact archive = snapshot. If an archive tarball is missing, OPAM attempts to create it (via= rsync/git), but if present, is treated as the most current tarball. You co= uld modify the XCP build system to run `opam-mk-repo` regularly and preserv= e the contents of archives/. (the latter may well be an undocumented feature of OPAM. Thomas Gazagnaire = is on vacation sailing the high seas at the moment. Unless we can get a fri= endly seagull to deliver this query, it will probably have to wait for his = return next week). Finally, for development purposes, you can also use 'opam pin' to force a p= articular package to a development version: $ opam pin mirage-net git://github.com/mirage/mirage-net $ opam update # this will refresh all the pinned remotes, either via rsync or git fetch $ opam upgrade # this will recompile all dependent libraries with the newest interface $ opam pin mirage-net none # this will unpin the package and go back to normal versioning. With sufficiently cunning pinning, you may not need to use the development = remotes for day-to-day use at all. -anil On 22 Oct 2012, at 08:42, Jon Ludlam wrote: > Hi all, >=20 > Firstly I'd like to add another voice in support of opam - it's been a ve= ry pleasant experience using it despite it's beta status, and so many of th= e developers here have become dependent on it that we're changing our XenSe= rver/XCP build system to build everything using it. >=20 > Before opam is officially announced (!) I'd like to raise an issue with v= ersioning which people may like to consider. Currently opam has several way= s of specifying the location of the source tarball for a package. By custom= , the packages are broadly categorised into rapidly developing packages and= stable packages. For rapidly developing packages, the source is often set = to be a pointer to github to the master branch, often because no 'stable' v= ersion exists. For stable packages, the url is often a pointer to a tarball= on the developers website, or sometimes a tagged release from github. >=20 > For our purposes, we need to be able to ensure that our builds are reprod= ucible, and hence need to know exactly which versions are installed. We had= hoped to achieve this by removing or disabling packages whose sources were= got directly from a master branch in github. However, it turns out that so= me packages that are 'stable' are dependent upon these packages, which seem= s brittle. The question is how to fix it? Should the opam repository mainta= iners require that 'stable' packages aren't dependent on 'unstable' ones? S= hould opam itself be aware of the difference and enforce this policy? If so= meone really wants to release a stable version of their thing and it's depe= ndent upon an upstream project with only a github repo, should the develope= r engage the upstream devs and request at least a tag, or should they make = their own tarball/github fork? >=20 > Many of these questions are social rather than technical, hence I'm posti= ng to the general ocaml list. >=20 > Cheers, >=20 > Jon >=20 >=20 > --=20 > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >=20