From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 70C5F138350 for ; Mon, 20 Apr 2020 20:51:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2915FE0A98; Mon, 20 Apr 2020 20:51:44 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DA073E0A6B for ; Mon, 20 Apr 2020 20:51:43 +0000 (UTC) Subject: Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development To: gentoo-dev@lists.gentoo.org References: <87imi6omoq.fsf@robot.e.airelinux.org> <7a4dba08-b18b-79d5-2fa6-62169ef39a4d@gmail.com> <87y2qsw0z3.fsf_-_@robot.e.airelinux.org> <512a263d-57b4-333f-39cf-ea99afad6bfd@gmail.com> <5dd8f5b8-d458-7f8c-a172-03a9066c5d17@gentoo.org> <8262877a-b935-66b3-68bc-87d81448247f@gentoo.org> From: Michael Orlitzky Message-ID: <2b5f4e49-9509-d00d-85d0-6dd7413f6e9c@gentoo.org> Date: Mon, 20 Apr 2020 16:51:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 9835f9a4-ba18-448e-807b-bf711bf3d07d X-Archives-Hash: 0e92d057f71fb16a023cdf940875304f On 4/20/20 4:21 PM, Georg Rudoy wrote: > вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky : >> But please quit looking to Go as an example of anything >> anyone should be doing. > > On a somewhat related note, I'd like to take this chance to ask about > packaging haskell software, which has somewhat similar issues: > > ... > 3. What is major is the following. Let's say two executables A and B > depend on libfoo:1 and libfoo:2 respectively, and depend on the same > version of libbar. libbar itself depends on libfoo (and supports both > versions), but libbar built with libfoo:1 is incompatible with libbar > built with libfoo:2. Loosely speaking, the slot of a library is > defined by all its dependencies' _versions_. > > Of all these, (3) is quite major, as it leads to exponential explosion > of the slots count. Otherwise, one might choose to carefully curate > the library versions, ensuring that no such situation arises, but this > approach is neither feasible nor possible at all for sufficiently > large packages base. There's nothing Haskell-specific here, is there? Except that Haskell as a research language tends to inspire more "fire and forget" software. (And Haskell works better in Gentoo than anywhere else, in my opinion.) You package each dependency as a separate package. If there's a conflict between two packages, then... you can't have those two packages installed together. When that happens, you alert upstream, and try to convince them to be more lenient with their dependencies (again, nothing Haskell-specific here). Sometimes that involves code changes, but often it's just an edit to the cabal file. Many people follow either semver or the PVP (https://pvp.haskell.org/) which keeps things from getting too far out of control. If upstream absolutely insists on minor-version dependencies, then you either tolerate it conflicting with everything else, or leave it out of the tree. You probably shouldn't even be packaging a library whose API is distinguishable across minor releases. Software engineering is a fractal. Curating APIs and dependencies is as much a part of it as what sorting algorithms you choose. These are all old problems with known solutions (sonames, semver, etc.) and software isn't magically high-quality because it's written in a language that came our last week. So aside from the "What's Gentoo?" that's going to be more common among Haskell upstreams, I don't see anything fundamentally different here between Haskell (or Go, or...) and C. We should be helping to make upstream software more good, and then packaging it. (It's OK to hack the cabal file while the bug report is open.)