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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6915E7F198 for ; Tue, 26 Jan 2016 17:57:06 +0100 (CET) IronPort-PHdr: 9a23:5A5j3BbSkDK5DShxrJHAWFv/LSx+4OfEezUN459isYplN5qZpcu/bnLW6fgltlLVR4KTs6sC0LqJ9fi4EjNYqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh7/0o8WYPF0ArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIZoGJ/3dKUgTLFeEC9ucyVsvJWq5lH/Sl6t62ERV2Qb2jZJBgnD61muXJvwtyr8scJ/0S+XJtHsQL0oHz+l6vE4ZgXvjXImKTc/uE7Qlstuh6JavAnp8x1hzKbVbYyYcv1kcfWOLpshWWNdU5MJBGR6CYSmYt5KVrJZMA== Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=ivg@ieee.org; spf=Pass smtp.mailfrom=ivg@ieee.org; spf=None smtp.helo=postmaster@mail-lf0-f49.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of ivg@ieee.org) identity=pra; client-ip=209.85.215.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of ivg@ieee.org designates 209.85.215.49 as permitted sender) identity=mailfrom; client-ip=209.85.215.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="ivg@ieee.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-lf0-f49.google.com) identity=helo; client-ip=209.85.215.49; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="ivg@ieee.org"; x-sender="postmaster@mail-lf0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CAAQAXpadWlTHXVdFehDhBBohRtAqGDwKBRAc8EAEBAQEBAQEBEAEBAQEHDQkJHzCCLYIUAQEBAwESER0BATcBBAsLCwMKKgICIhIBBQEcBhMih3EIoXGBMT4xik1nhEABBIphAQEBAQEBBAEBAQEBARQGCoYohG2HTIE6jTJ0iFiIOAWFGYFejRtEhS6HFBEfgQ03gh8eIoFTHi4BiEMBAQE X-IPAS-Result: A0CAAQAXpadWlTHXVdFehDhBBohRtAqGDwKBRAc8EAEBAQEBAQEBEAEBAQEHDQkJHzCCLYIUAQEBAwESER0BATcBBAsLCwMKKgICIhIBBQEcBhMih3EIoXGBMT4xik1nhEABBIphAQEBAQEBBAEBAQEBARQGCoYohG2HTIE6jTJ0iFiIOAWFGYFejRtEhS6HFBEfgQ03gh8eIoFTHi4BiEMBAQE X-IronPort-AV: E=Sophos;i="5.22,350,1449529200"; d="scan'208,217";a="199489593" Received: from mail-lf0-f49.google.com ([209.85.215.49]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 26 Jan 2016 17:56:57 +0100 Received: by mail-lf0-f49.google.com with SMTP id c192so109080202lfe.2 for ; Tue, 26 Jan 2016 08:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RhvJR446ExsS7PJmF3N9aR7ZgqIAYqDKHxngjfh57Dk=; b=PzUK1cVzdwDRgPZbaf2aRKxgmEO3b616Cu/H7JwpeQGzLpebGQPabjU/F03K16kBJ7 XUoKLhIQLUI163BLFlW4t1yteQAoflqDFHynmzlfkPUk2pvQIT2z6rjA5g2hIzP+QeUa Xf/OEHbagYOVVnuc9vKPJ2Y3MFXRnLcgf3Y6jQ359ZfLdV4lUFyWSEMK+gUFRBKM8kMk 7fUdk8KgIvzVz0jnBYbFjXW4zULZPrkWE4vv905pmkECJ31aboBS38Fox6LhCh2+r7GI lcp0m8PPrvIBZUhFuTdPINTGTO+ZPh6BxKJ2P+d62qO0Rlglal2NfM/prrjZ3mFWYrxX 9VPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RhvJR446ExsS7PJmF3N9aR7ZgqIAYqDKHxngjfh57Dk=; b=HzQrzLuxhf2R+LlO1gjBw41icfExjz8pmL17QXAp3lDV2vH4Phj+OOhcZHwn3KEI89 ZqtHVT2v7Po7qLD6twy77gZf4tQSs5OTZaq3JUgcF4UwzQ8sb5QEwn5Z9CrvQeAlbMr8 z2BbvJ9ZfHFgObpZVTs77IH3FkoWfUcslx+++Al1Pe3YPdGDsaYBseB2pWVlBbBedmoh WGtvGWQbf86yrIhN3DD+VV0RKHDzyooC+NQGokYhAQfzS8i7CgzY30g9THQ5NUfIXEBF x12dfqE4N8rH2RXf0bO7chf0t2YZ7/vMKJkqYbbtndB6pNBOHgVuZpLospBXMwgO3EG8 m2Nw== X-Gm-Message-State: AG10YOROqr3p3ji/1MbNm4b4PoI4bxmRTW178nVmAD2HSYcQXilbCCJ82oF3+KsqP1Ze3+mQKRhQqv4jNK67CSsi MIME-Version: 1.0 X-Received: by 10.25.160.1 with SMTP id j1mr9497898lfe.35.1453827417136; Tue, 26 Jan 2016 08:56:57 -0800 (PST) Received: by 10.114.183.52 with HTTP; Tue, 26 Jan 2016 08:56:57 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Jan 2016 11:56:57 -0500 Message-ID: From: Ivan Gotovchits To: Jeremie Dimino Cc: "ocaml-core@googlegroups.com" , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a114021f6c38f57052a3f9209 Subject: Re: [Caml-list] Package renamings for sexplib, bin_prot and a few other camlp4 syntax extensions --001a114021f6c38f57052a3f9209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > 3. release project.0.3.1, keeping project.0.3 unchanged The problem is that `project.0.3` will be broken for ever, as well as all dependencies that depend on this particular version. Maybe there is actually some misunderstanding, and we're talking about different things. Just to clarify, are you going to go through opam-repository and update all archives of old libraries (e.g. sexplib.7.0.5, sexplib.108.00, ...) and remove `.syntax` findlib library from it? This is what I'm afraid of. And this is what I name "retroactively". As according to the PR there is nothing like this. If all old archives will be still available, then it is perfectly fine. > =E2=80=8BFor merlin and oasis we just need to add pa_sexp_conv.syntax, we= 'll do that. This is what I'm proposing. > I don't know bap very well, does it have "sexplib.syntax" hardcoded =E2= =80=8Bin its source code or is the same situation as merlin and oasis? Yep, but it is not a problem to me to fix it. I'm just wondering are there any more packages, that provide build systems, that can have such problems. Maybe just grepping the opam universe will help in answering this question. On Tue, Jan 26, 2016 at 11:15 AM, Jeremie Dimino wrote: > On Tue, Jan 26, 2016 at 3:15 PM, Ivan Gotovchits wrote: > >> > Do you know of any tool that rely on this? >> >> OASIS it the most notable [1]. >> > > =E2=80=8BAh, I didn't know about this hack=E2=80=8B, and apparently it's = the same hack for > merlin. Well, we can certainly add ".syntax" packages to pa_sexp_conv and > others then > > >> 1. Delete `project.0.3` from the repository and add new `project.0.3-???` >> with a fixed build system >> 2. Retrospectively modify `project.0.3` build system and upload a new >> tarball without changing a library. >> > > =E2=80=8BI was thinking of: > > 3. release project.0.3.1, keeping project.0.3 unchanged > > That the same as what one would have to do if the API changed in an > incompatible way. > > >> Also, some packages, may encode library names in the code itself. For >> example, bap uses this to track dependencies of dynamically loaded plugi= ns. >> Merlin has a heuristics, that >> guesses requested syntax extensions based on package names. >> > > =E2=80=8BFor merlin and oasis we just need to add pa_sexp_conv.syntax, we= 'll do > that. > I don't know bap very well, does it have "sexplib.syntax" hardcoded =E2= =80=8Bin > its source code or is the same situation as merlin and oasis? > > -- > Jeremie > --001a114021f6c38f57052a3f9209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> 3. release project.0.3.1, keeping project.0.3 unchang= ed

The problem is that `project.0.3` will be broken = for ever, as well as all dependencies that depend on this particular versio= n.=C2=A0

Maybe there is actually some misunderstan= ding, and we're talking about different things. Just to clarify, are yo= u going to go=C2=A0
through opam-repository and update all archiv= es of old libraries (e.g. sexplib.7.0.5, sexplib.108.00, ...) and remove `&= lt;library>.syntax`=C2=A0
findlib library from it? This is wha= t I'm afraid of. And this is what I name "retroactively".
As according to the PR there is nothing like this. If all old archiv= es will be still available, then it is perfectly fine.

=
> =E2=80=8BFor merlin and oasis we just need to add pa_sexp_conv.sy= ntax, we'll do that.

This is what I'm prop= osing.=C2=A0

> I don't know bap very well, = does it have "sexplib.syntax" hardcoded =E2=80=8Bin its source co= de or is the same situation as merlin and oasis?

Y= ep, but it is not a problem to me to fix it. I'm just wondering are the= re any more packages, that provide build systems, that can have such proble= ms.=C2=A0
Maybe just grepping the opam universe will help in answ= ering this question.




On Tue, Jan 26,= 2016 at 11:15 AM, Jeremie Dimino <jdimino@janestreet.com> wrote:
On Tue, Jan 26, 2016 = at 3:15 PM, Ivan Gotovchits <ivg@= ieee.org> wrote:=
<= div>> Do you know of any tool that rely on this?

OASIS it the most notable [1].=C2=A0
=
=E2=80=8BAh, I didn't know about this hack=E2= =80=8B, and apparently it's the same hack for merlin. Well, we can cert= ainly add ".syntax" packages to pa_sexp_conv and others then
=C2=A0
1. Delete `project.0.3` from the repository and add new = `project.0.3-???` with a fixed build system
2. Retrospectively mo= dify `project.0.3` build system and upload a new tarball without changing a= library.

=E2=80=8BI = was thinking of:

3. release project.0.3.1, keeping pro= ject.0.3 unchanged

That the same as what one would hav= e to do if the API changed in an incompatible way.
=C2=A0
Also, some packages, may encode library names in the code itself. For exam= ple, bap uses this to track dependencies of dynamically loaded plugins. Mer= lin has a heuristics, that
guesses requested syntax extensions ba= sed on package names.=C2=A0

<= div>
=E2=80=8BFor merlin and oasis we just need to add pa_= sexp_conv.syntax, we'll do that.
I do= n't know bap very well, does it have "sexplib.syntax" hardcod= ed =E2=80=8Bin its source code or is the same situation as merlin and oasis= ?

=
--=C2=A0
Jeremie

--001a114021f6c38f57052a3f9209--