From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 58836BC69 for ; Wed, 26 Sep 2007 12:37:16 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANHS+UbAXQInemdsb2JhbACOLQEBCQo X-IronPort-AV: E=Sophos;i="4.20,301,1186351200"; d="scan'208";a="1807388" Received: from concorde.inria.fr ([192.93.2.39]) by mail2-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 12:37:16 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QAbAXN024748 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 12:37:16 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANHS+UZQW+UCh2dsb2JhbACOLQEBAQgKJw X-IronPort-AV: E=Sophos;i="4.20,301,1186351200"; d="scan'208";a="1502256" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 12:37:11 +0200 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IaUDD-0000yy-31 for caml-list@inria.fr; Wed, 26 Sep 2007 10:33:47 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Sep 2007 10:33:47 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 26 Sep 2007 10:33:47 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: Cherry-picking modules (was Re: [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) Date: Wed, 26 Sep 2007 10:26:11 +0000 (UTC) Message-ID: References: <46F95938.7030107@cs.umd.edu> <17487E59-04F2-4509-87B5-24377B051E9E@epfl.ch> <46F961E5.5060302@cs.umd.edu> <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/0.9.8.1pl2 (Debian) Sender: news X-Miltered: at concorde with ID 46FA3657.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 ocaml:01 buenzli:01 ocaml:01 avoided:01 bug:01 bug:01 recompiled:01 mldonkey:01 distro:01 ocamlfind:01 2007,:98 wrote:01 minor:01 minor:01 On 26-09-2007, Daniel Bünzli wrote: > > Le 26 sept. 07 à 01:33, Sylvain Le Gall a écrit : > >> Anyway, embeding any external code into your project is a nightmare >> for >> security/maintenance in the long term... I would avoid this >> solution if >> i want things that doesn't have problem. > > As I explained I don't think so. In the best case you delegate the > nightmare to the user. Can you explain exactly where the nightmare is > with embedding ? If the distributed modules you integrate are > labelled with a version, I don't see it. The work needed for > maintenance in the long term is exactly the same, except only the > developer has to care. As for security updates in ocaml, you cannot > anyway rely on dynamic linking. Which I see as a good thing, for > applications dynamic linking creates more problems than it solves and > should be avoided most of the time (except of course for system > libraries). > OK, let me make myself clear, about the fact that embedding things is the worst case. Let consider library libA and program progB, progB requires libA: * libA is embedded inside progB: ** libA do a minor bug correction -> you need to re-release progB even if nothing has changed inside it ** you make a bug correction in libA, as many developers you don't have time to submit bug upstream -> libA upstream and libA embedded begin to be different * libA is not embedded inside progB: ** libA do a minor bug correction -> progB just need to be recompiled (no release), easy to do automatically with a dependency tracking ** you make a bug correction in libA -> you have no choice than to report it to upstream libA, because your bug correction will disappear in next libA release Unfortunately i have seen projects (like mldonkey) which has embedded a lot of libraries. The result of this is that you only creates branches, with no real feedback to upstream author. This is a shame, it duplicates works of bug correction for libA upstream and progB. It is funny, because when you see other big languages -- which are working very well -- like Perl, they all try to avoid embedding libraries! The only real needs is to have something that automatically download/build/install dependency! AND WE HAVE IT: godi! Or if you want things more distro based: debian... Off course, as long as you will think that you must embed everything, you won't need to learn godi (which is very simple) and you won't evolve on this point. I really do invite you to try godi/ocamlfind? These tools are really great and are a solution for the kind of problems you describe.. Regards, Sylvain Le Gall