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 AB63C7F1CB for ; Wed, 12 Dec 2012 18:37:27 +0100 (CET) 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: AicHACzAyFBZELGa/2dsb2JhbABFg0ioe5Jpc4IeAQEEAXkFCwtGRRIGExSHawMJCgi9cQSLYmmDYmEDlDeBUos3hRGCcw X-IronPort-AV: E=Sophos;i="4.84,267,1355094000"; d="scan'208";a="165641564" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail4-smtp-sop.national.inria.fr with SMTP; 12 Dec 2012 18:37:26 +0100 Received: (qmail 19305 invoked by uid 634); 12 Dec 2012 17:36:45 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from cpc7-cmbg14-2-0-cust238.5-4.cable.virginmedia.com (HELO [192.168.1.48]) (86.30.244.239) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Wed, 12 Dec 2012 17:36:45 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Anil Madhavapeddy In-Reply-To: <1355323620.61324.YahooMailNeo@web120404.mail.ne1.yahoo.com> Date: Wed, 12 Dec 2012 17:36:43 +0000 Cc: OCaml mailing-list Content-Transfer-Encoding: quoted-printable Message-Id: <70C3E286-D817-453A-AEBE-DE7B2C69C879@recoil.org> References: <1355323620.61324.YahooMailNeo@web120404.mail.ne1.yahoo.com> To: Dario Teixeira X-Mailer: Apple Mail (2.1498) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] OPAM conventions On 12 Dec 2012, at 14:47, Dario Teixeira wrote: > Hi, >=20 > I've been looking at the OPAM package database -- trying to determine ove= rall > conventions and best practices -- and I came across some inconsistencies. > Though in most cases these are purely cosmetical, I reckon that neverthel= ess > we could all benefit if some standardisation is agreed upon on. Examples: >=20 > 1) Package naming >=20 > For some values of "foo", OPAM's package name for project "ocaml-foo" > is also "ocaml-foo", whereas for others is simply "foo". This is an > ackowledged issue by OPAM developers: > https://github.com/OCamlPro/opam-repository/issues/163 >=20 > In my mind, there are only two sensible policies for naming OPAM packag= es: >=20 > a) OPAM packages should preserve the name of the original project. > Thus, if the project is named "ocaml-foo", the OPAM package will > also be "ocaml-foo". >=20 > b) OPAM packages should have the same name as the findlib entry. > If project "ocaml-foo" registers itself in findlib with name > "foo", then "foo" should also be the name of the OPAM package. >=20 > Good arguments can be made for and against each option. Though this > is largely a bike-shedding issue, I think the community should make > a decision sooner rather than later. I generally don't like typing too much, and so prefer the shorter name. But converting packages names isn't really a big deal and can be done mechanically, so it's more important to build up the database first. >=20 > 2) Invoking executables >=20 > To invoke, say, a configure script, some packages will nonchalantly > just declare ["./configure"] whereas others will ask the shell to > do it: ["sh" "configure"]. While either should work in any Unix > system, should one be preferred for compatibility with more exotic > systems? If the upstream package has the configure script marked as executable, then ./configure should be fine. Some don't (this used to be a bigger problem when some VCS's couldn't track file modes, but isn't an issue in modern systems). > 3) Package removal >=20 > For most values of "foo", package "foo" will just declare ["ocamlfind" > "remove" "foo"]. However, this approach seems a bit brittle to me. > If the Makefile supports "uninstall" (which is the usually the case > for OASIS packages), then I reckon that ["%{make}%" "uninstall"] > should be preferred. >=20 > Having said that, it seems that ["%{make}%" "uninstall"] is currently > not working (OPAM tries to download the package de novo upon removal!). > Is this a bug or a feature? The issue with removal is that the package needs to be available to run make uninstall, hence the download. In the longer term, we've discussed letting the OPAM package declare which ocamlfind packages it installs, and having those automatically handled (i.e. the install phase asserts that the package exists as a post-condition, and the uninstall removes it and checks it's gone). But that's all post-OPAM-1.0! Basics first. > 4) Findlib dependency >=20 > Most packages do declare a dependency on ocamlfind. However, this is > not universal, even for packages that do register themselves with find= lib. > What should be the standard here: always declare a dependency, or omit > it altogether since it is implied? If something uses ocamlfind and doesn't declare it explicitly, it's a bug. The continuous build system catches most of these, and in practise it doesn= 't matter as a dependent package will pull it in, but it's best to be explicit about it. -anil=