From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTP id 1D4905D4 for ; Tue, 11 Dec 2018 03:09:50 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,340,1539640800"; d="scan'208";a="359709657" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 11 Dec 2018 04:09:49 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 0161882561; Tue, 11 Dec 2018 04:09:48 +0100 (CET) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id AD9FF824E4; Tue, 11 Dec 2018 04:09:39 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=mlists@ligand.eu; spf=Pass smtp.mailfrom=mlists@ligand.eu; spf=None smtp.helo=postmaster@relay6-d.mail.gandi.net IronPort-PHdr: =?us-ascii?q?9a23=3APxaGkh31xpygF7W5smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?se0fLvad9pjvdHbS+e9qxAeQG9mDu7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLnhz?= =?us-ascii?q?sIOTE3/m/XlMJ+kaBUoByiqR1wzYHZe52VOfl8fq/BYd8XX2hMU8BMXCJBGIO8?= =?us-ascii?q?aI4PAvIBM+ZCtYb9oUcBrRy/BQm3Geji1yFHhmXo0q083OQuDxvG1xEnEtILtH?= =?us-ascii?q?TUrc71NLsJUe2uyKnIzDrDYOlQ2Tjg8oTHbA0hrOiKULltcsTR0VEiGx3YgliS?= =?us-ascii?q?s4DoPS+Z2v4Qv2WY4edsT/+jhmokpgx3vzOh3N0jipPTiYIQ0l3E9Tt2wIIyJd?= =?us-ascii?q?CgUk50f9qkH4FQtiybLod5X9kuQ2RytyY7zr0Ko5G7czIMyJs6xh7TcfqHfJaU?= =?us-ascii?q?4h77VeaRJyl3hG59db6hmhq/81Ksx+/gWsWuzVpHrSRInsPRun0J1BHf8s2HRe?= =?us-ascii?q?F8/kel1zaPzQfT6uRcLEAxkarbKoUhwqIrlpcItUTDHyD2l1/wjKCLbEkr5PWo?= =?us-ascii?q?5/z9Yrr6vp+cK5N0igbmP6sygMO/BOA4PhEKX2ia4uS8yKTv/VfnT7VTk/05jL?= =?us-ascii?q?LZsIzBKMQApq+5BhdV3Zw55xa+CTemytUYkmMdIFJLYhKNl5LpNE3WIPDkEfe/?= =?us-ascii?q?hEyhnytxyPDDOr3tG5HNLnnYkLf9Zrt98E5dyA8rzd9F/Z5UC7cBIOjyWkDrrt?= =?us-ascii?q?DYAAU5YESIxLPsAdB5np4FVHiUSvuSOabW9FuJ/f4HIu+WZYZTtiyreNY/4Pu7?= =?us-ascii?q?o2Uwn1QafLLh95YNZXa3E+4ud0CdYGHwmf8FEGgDuAZ4QfG82w7KaiJae3vnB/?= =?us-ascii?q?F03To8Eo/zVd6SFLDou6SI2WKAJrMTY2lHDl6WFnKxLteAWvgFbi7UL9Izy2VY?= =?us-ascii?q?B4jkcJco0FSVjCG/06Bud7OG/iwXvJTvktVotbWKyEMCsAdsBsHY6FmjCmF5mm?= =?us-ascii?q?RSGm0s0aR2sBI4xhGG2Kl8xfNRE9BSofVETlViOA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgBfKQ9ch8a3RtlkHAEBAQQBAQcEA?= =?us-ascii?q?QGBZYM5MyeDe4h4izFQAQEGUmOBIYdxDpArDYRsAoMrGgcBBDQSAQMBAQIBAQE?= =?us-ascii?q?BARMBAQEKCwkIGw4vgjYigmUBAgMjDwEFQRAEBxgCAiYCAiE2BhMIgxmBagMIE?= =?us-ascii?q?aYGgS+IBA2CHIELh3yDGhd4gQeBEYMSgleFLoJXAok1hgh8j2cnLgmOIIMnCBi?= =?us-ascii?q?BXI9hiieEfIdmgieBXYF3Hy4mEjuCbII1jjUwAzCLZgEB?= X-IPAS-Result: =?us-ascii?q?A0ACAgBfKQ9ch8a3RtlkHAEBAQQBAQcEAQGBZYM5MyeDe4h?= =?us-ascii?q?4izFQAQEGUmOBIYdxDpArDYRsAoMrGgcBBDQSAQMBAQIBAQEBARMBAQEKCwkIG?= =?us-ascii?q?w4vgjYigmUBAgMjDwEFQRAEBxgCAiYCAiE2BhMIgxmBagMIEaYGgS+IBA2CHIE?= =?us-ascii?q?Lh3yDGhd4gQeBEYMSgleFLoJXAok1hgh8j2cnLgmOIIMnCBiBXI9hiieEfIdmg?= =?us-ascii?q?ieBXYF3Hy4mEjuCbII1jjUwAzCLZgEB?= X-IronPort-AV: E=Sophos;i="5.56,340,1539640800"; d="scan'208";a="288592968" Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2018 04:09:38 +0100 Received: from webmail.gandi.net (webmail5.sd4.0x35.net [10.200.201.5]) (Authenticated sender: mlists@ligand.eu) by relay6-d.mail.gandi.net (Postfix) with ESMTPA id DBE40C0002; Tue, 11 Dec 2018 03:09:37 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 11 Dec 2018 12:09:37 +0900 From: Francois Berenger To: caml users Cc: caml-list-request@inria.fr In-Reply-To: <8736r9mbho.fsf@x80.org> References: <966B3CBE-29BB-4336-BDBF-0012723E7099@math.nagoya-u.ac.jp> <87va45odpo.fsf@x80.org> <8736r9mbho.fsf@x80.org> Message-ID: X-Sender: mlists@ligand.eu User-Agent: Roundcube Webmail/1.1.2 Subject: Re: [Caml-list] LablGtk3 beta1 Reply-To: Francois Berenger X-Loop: caml-list@inria.fr X-Sequence: 17236 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 08/12/2018 03:34, Emilio Jesús Gallego Arias wrote: > Hi Gabriel, > > Gabriel Scherer writes: > >> If several OCaml package have system dependencies in common, (of >> several versions of the same OCaml package), indicating depexts >> per-package duplicate the information. This is what we were doing >> before and in practice most package depexts were perpetually >> out-of-date. >> >> Some information in the conf-package is rather canonical from system >> to system (such as: the pkg-config name, even though there is still >> variation unfortunately), some is highly system-dependent (the package >> name in the package manager); I think it's reasonable to also have the >> "canonical" information in the build system. > > Umm, indeed that may make sense very widely used packages, such as > `m4`, > etc... I am not sure this makes sense for gtk tho; right now we have: > > lablgtk2.opam > lablgtk2-glade.opam > lablgtk2-gnomecanvas.opam > lablgtk2-gspell.opam > lablgtk2-rsvg.opam > lablgtk2-gl.opam > lablgtk2-gnome.opam > lablgtk2-sourceview2.opam > > so adding so many conf- packages seems like a nuisance. Also it is > harder for consumers of the library to depend on the right packages; > this is the reason Debian uses this scheme: > > liblablgtkmathview-ocaml-dev > liblabltk-ocaml-dev > liblablgl-ocaml-dev > liblablgtk2-gnome-ocaml-dev > liblablgtk-extras-ocaml-dev > liblablgtksourceview2-ocaml-dev > liblablgtk2-gl-ocaml-dev > liblablgtk2-ocaml-dev > > I much prefer to depend on `lablgtk-sourceview` than on `lablgtk` and > `conf-gtksourceview`; not to say the issue with the side effects [see > below] > >> Also, conf-* packages are very early in the dependency tree, so a >> pragmatic advantage is that they will fail early in the build, >> typically before you have installed all the OCaml dependencies and you >> start building the package itself. (Also, depending on the >> configure/build system, you may geta nice error if a dependency is >> missing, or a crappy compilation failure that can be hard for users to >> interpret). > > In this case the error messages are the same I think. I am not sure the > "early in the build tree" is so important tho. > >> If you edit a package to update system dependencies, you have the same >> recompilation issues. If you have to recompile *more* in the case of >> a conf-* package, it is because it introduced dependency sharing, >> which is a good thing -- making the repository more maintainable. > > The thing is that I am coming from a world (Debian) were package builds > are required to be deterministic; what does editing a package to update > system dependencies mean? How is the repository going to be more > maintainable? > > For example, in this case, installing `conf-gl` will force the > recompilation of `lablgtk`, and `conf-gl` could be pulled by an > unrelated package. > > It seems very wrong to me that this sharing will actually force a > side-effect on a unrelated package. > > IMVHO this is very non-standard behavior that I've only seen in OPAM > and > makes things less maintenable indeed, for example if you want to have > Debian packages. > >> I don't understand, the point is for lablgtk2-sourceview2 to depend >> on conf-gtksourceview2, so you should just use the first command >> and the conf-* package(s) will get installed as well. > > I could do that, but what is the point on shipping a fake, empty > package > then? `lablgtk2-sourceview2` can handle the dependencies just fine. > > An even worse problem is this case: imagine package A and B both depend > on gtksourceview, however package A requires version > 2.10 and package > B version > 2.11. Oh, this one is an interesting question! You are suggesting that opam should support the installation of different versions of the same thing. I think nix can do that, and that indeed looks like a current limitation of opam. Regards, F. -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list https://inbox.ocaml.org/caml-list Forum: https://discuss.ocaml.org/ Bug reports: http://caml.inria.fr/bin/caml-bugs