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 mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id A0E0A7F1CB for ; Wed, 12 Dec 2012 19:01:34 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of wojciech.meyer@gmail.com) identity=pra; client-ip=209.85.217.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of wojciech.meyer@gmail.com designates 209.85.217.182 as permitted sender) identity=mailfrom; client-ip=209.85.217.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lb0-f182.google.com) identity=helo; client-ip=209.85.217.182; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="postmaster@mail-lb0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAMvFyFDRVdm2m2dsb2JhbABFrEOSSwgWDgEBAQEBCAkLCRQngh4BAQQBQAEbHQEDDAYFCw0VGSIBEQEFAQoSBhMUh2oBAwkGnwSMM4J7hQMKGScNWYh2AQUMi1ZpgQ6DNQOUN4FSizeDMRYphBQ X-IronPort-AV: E=Sophos;i="4.84,267,1355094000"; d="scan'208";a="185848849" Received: from mail-lb0-f182.google.com ([209.85.217.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 12 Dec 2012 19:01:34 +0100 Received: by mail-lb0-f182.google.com with SMTP id go10so1032473lbb.27 for ; Wed, 12 Dec 2012 10:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kR09s9pSsJyzIiD584hvFrGwAY7/x3O2s7SCFuX8MeU=; b=uSnXUlewJuYTLDHX88oBMsK+m1cksvSaBfED9KScDSqR8MfQo2Y1+CYS1iUBEvFHKg Ed5BruSfcD35f0QI7OydQOqaEpaQiJ8dwhnwGFbolca0UmCa2DiCWkbYJPuJ7MTJ/mJr AX9kDP5LAusOeB74MdaOEIWieJhxYdhNDAM7V/if0o4vseCvp3CiyE4iahHoWa2AqFca xikmlu/a6b3oya5kw8soN3RPjAnN6eaZWf3/K6tDiWXSlRjXWtKGFPTLwl2jDjKxelAh fNOsQL+GLsArcI9EYc7uZR3iDswGInT38o0ACVh/Vlz8LL0qMoeP/i3Lv+1l86r6hWXj p4MA== MIME-Version: 1.0 Received: by 10.152.148.4 with SMTP id to4mr1894845lab.39.1355335293633; Wed, 12 Dec 2012 10:01:33 -0800 (PST) Received: by 10.114.15.41 with HTTP; Wed, 12 Dec 2012 10:01:33 -0800 (PST) In-Reply-To: <70C3E286-D817-453A-AEBE-DE7B2C69C879@recoil.org> References: <1355323620.61324.YahooMailNeo@web120404.mail.ne1.yahoo.com> <70C3E286-D817-453A-AEBE-DE7B2C69C879@recoil.org> Date: Wed, 12 Dec 2012 18:01:33 +0000 Message-ID: From: Wojciech Meyer To: Anil Madhavapeddy Cc: Caml List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Caml-list] OPAM conventions On Wed, Dec 12, 2012 at 5:36 PM, Anil Madhavapeddy wrote: > On 12 Dec 2012, at 14:47, Dario Teixeira wrote: >> 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. Indeed, but then dependent packages needs to be up-dated too! We could have also virtual packages that could serve as a basis for aliases when there is a strong reason to be compatible. The good thing is that OPAM package definitions are detached from the tarballs itself, so it's easy to up-date in a centralised way. >> 3) Package removal >> >> 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. >> >> 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. Hmm, wouldn't be just better for OPAM to track the diff of the repository, then just remove the files? Possibly, having an open door for unnistall would be good for packages like Ocsigen which might want to remove the configuration from the system or shutdown the server. > > 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 >> >> Most packages do declare a dependency on ocamlfind. However, this is >> not universal, even for packages that do register themselves with findlib. >> 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. +1. I'm also always convinced that ocamlfind should be taken into account as an integral part of the system. -Wojciech