From nobody Tue May 17 12:52:10 2022 X-Original-To: freebsd-erlang@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 141831B38669 for ; Tue, 17 May 2022 12:52:38 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4L2bcj2mn8z3rlg for ; Tue, 17 May 2022 12:52:37 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6763D5C0116; Tue, 17 May 2022 08:52:31 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute2.internal (MEProxy); Tue, 17 May 2022 08:52:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1652791951; x= 1652878351; bh=8ao3Mr/KqRnw14zPego8KESya0rASALJwS1zlVz5Be8=; b=N X+zrRLUSvdkgXqXoqEBIEyJMn2Qx+3+klJVN84vo7JvLc0TZkQWojHcMy6ZddWH3 FEl0vyMInBdz3Ofu+vsPS5TOmHIA3FcBo13fJmwP/GO9g4YKFOM8nLeSa9H2149w /RiaCmyCNEge9pKERromeZ3s/H8fd7hFJd8h6iBaPVvza+Ed6kULvP3nRDXnI/5/ mXLMvRnToHBLj2AD10dRVh1k5DygWeMpj4eQnRWDV3zOWLc58Whod/4auzVsQlc2 abx1ppXE4mm73W+IW4v5vSi55Tqm+zM2z7KA3u+qXWB2Os2Q+f9/vfloR2HpYUWp lZPxdVmWtcOqm1QwNLisw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1652791951; x=1652878351; bh=8 ao3Mr/KqRnw14zPego8KESya0rASALJwS1zlVz5Be8=; b=kDOOkbnQvQQm3HpDs ddAC7h0YdRZPdPfgLIVEe8eN/LyVgAHhBn6w3zH7g0eJ6rWmfYcbDO6/E4JHBfIJ pzf722bKLPFaSn6Xf1RJ96FlhFYxVfOaxAIpMmuc7EttoHQaFiBc2EWfGa/RvHiM rugGgLOAuiHh4sX0cl0xsf16rl96h2dXlRhUp0AxIHlU461vWbk1yD7rgglkFe6E lNsgGgLt9N+CP6lpIToSxcKtuc+EUrKwenv5XhrKPPyiT/1qFy3PCxiVg2CV3Gaj dAlDzWVIzpnk0GONbWWfXMS5ZcBPJBkstr+vjtVzpSyHqLQc+rRgySZxZi0+hDFZ kZIWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrheejgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfffgrvhgvucevohhtthhlvghhuhgsvghrfdcuoegutghh sehskhhunhhkfigvrhhkshdrrghtqeenucggtffrrghtthgvrhhnpeeuvdfghfetjedtue fhveekveefgfelvefftdffieevkedtgfeiteejfffgheffhfenucffohhmrghinhepfhhr vggvsghsugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpegutghhsehskhhunhhkfigvrhhkshdrrght X-ME-Proxy: Feedback-ID: ic0e84090:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1BE6336A0060; Tue, 17 May 2022 08:52:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27 List-Id: Support of Erlang-related ports List-Archive: https://lists.freebsd.org/archives/freebsd-erlang List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-erlang@freebsd.org Mime-Version: 1.0 Message-Id: <4c572e79-2744-412a-94d0-ec0eb48f3144@www.fastmail.com> In-Reply-To: <88FB0E34-FBB2-4257-A1C8-4F24B9BA130F@patmaddox.com> References: <88FB0E34-FBB2-4257-A1C8-4F24B9BA130F@patmaddox.com> Date: Tue, 17 May 2022 12:52:10 +0000 From: "Dave Cottlehuber" To: erlang , "Pat Maddox" Subject: Re: Why the difference between lang/elixir and lang/elixir-devel? (also: elixir-devel doesn't support mix release) Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4L2bcj2mn8z3rlg X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm2 header.b="N X+zrRL"; dkim=pass header.d=messagingengine.com header.s=fm1 header.b=kDOOkbnQ; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 66.111.4.27 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-3.45 / 15.00]; XM_UA_NO_VERSION(0.01)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.27]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.86)[-0.859]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.27:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; SUBJECT_HAS_QUESTION(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm2,messagingengine.com:s=fm1]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[skunkwerks.at]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-erlang]; MID_RHS_WWW(0.50)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 10 May 2022, at 04:12, Pat Maddox wrote: > I had been working on a patch to lang/elixir-devel to support mix=20 > releases, per the problem I shared in=20 > https://lists.freebsd.org/archives/freebsd-erlang/2022-May/000629.html > > When working on it, I saw that lang/elixir doesn=E2=80=99t have the pr= oblem -=20 > it doesn=E2=80=99t patch `elixir` to =E2=80=9Chard-wire=E2=80=9D the O= TP release. So I can=20 > just depend on lang/elixir instead. > > I had assumed that lang/elixir-devel just provided a more up-to-date=20 > version of elixir, to get access to a newer elixir while still using=20 > quarterly ports. > > That appears not to be the case. Two key differences I note are: > > 1. lang/elixir depends on lang/erlang, whereas lang/elixir-devel depen= ds=20 > on lang/erlang-runtime* > 2. lang/elixir builds elixir as-is, whereas lang/elixir-devel patches=20 > the `elixir` script to =E2=80=9Chard-wire=E2=80=9D the OTP release. > > What is the intent of the lang/elixir-devel port? Hi Pat TLDR log an issue against lang/elixir-devel for fixing mix release & tracking this. The OTP21-OTP22 transition was a major breakage point for OTP stdlib and stuff needed to be hard wired to work reliably. -devel flavoured ports are the leading edge of ports dev. As a ports committer it allows me to easily switch a subsidiary port (like net/rabbitmq or phoenix) over for testing, as I choose, & back again. As a user, it allows me to test my apps against the very latest. A little bit of history. In FreeBSD ports, we have had since time immemorial: lang/erlang: the main stable OTP release, which the ports variants (-java -wx -man -doc) are built off, and corresponding tools like rebar & elixir are built from. lang/erlang-runtime${...}: same build system, newer & older OTP releases, to accommodate dependencies that were ahead or behind of the curve. The bytecode produced by different erlang versions isn't fully compatible between versions. We needed, at least in previous releaess, to ensure th= at newer elixir is always built (and therefore used) against newer bytecode= s. This was particularly relevant when erlang native-compiler and hipe was still common. For quite a while we had elixir versions that could only be built off the newer OTP releases, thus erlang-runtime${...} dependent, and thus the build hooks, your #2. Last year, we cleaned up and deprecated ports that were not buildable on recent supported OTP releases. This was really only moving along once the OTP team declared their official support policy, prior to that we ju= st kept everything back to ~R15~. Last year, OTP24 was released, with JIT support, and this felt new enough to not switch things over to it by default, and yet ideal for an elixir-devel port to link & test against. At that time, lang/erlang was still OTP21, and a very large number of erlang & elixir modules would work on OTP21 and break on OTP22+ due to significant changes & deprecati= ons in OTP stdlib (logger, hipe, NIF API, crypto, erl_interface, ...) so we needed to keep these things separate. This year, when OTP25 is released, OTP21 will no longer supported, and any dependent library that hasn't upgraded their supported OTP releases can be removed from ports tree too, as clearly they're not keeping up.=20 We can switch lang/elixir-devel to use any OTP release, as the lang/elix= ir port now does. A+ Dave