From owner-freebsd-ports@freebsd.org Thu Feb 9 23:04:33 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4E38CD8780 for ; Thu, 9 Feb 2017 23:04:33 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id CB6EF1B30 for ; Thu, 9 Feb 2017 23:04:33 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: by mailman.ysv.freebsd.org (Postfix) id C9492CD877E; Thu, 9 Feb 2017 23:04:33 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8F30CD877D for ; Thu, 9 Feb 2017 23:04:33 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from relay.waschbuesch.it (relay.waschbuesch.it [IPv6:2a00:cba0:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B0C91B2E; Thu, 9 Feb 2017 23:04:33 +0000 (UTC) (envelope-from martin@waschbuesch.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pTHZF56VexZx+sdsMxzy2RYa4z5iX5n4LY8JuPOAmd4=; b=elUW+7RJXAlimCYrWKsywmAm6 JgVv90I+YWQ1o/3SswygJHAr4HEPSGajMx+Upifwj7xpKC6N7uYCVgqxP+sMu7C3LFSMmIaNrDT78 l7BG/SwqTZo8g/hp55hvGWhvvWAhLUTJix3H0FiCPrkzPGtulPBBXpfz1ft958VErKq6I=; Received: by relay.waschbuesch.it with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim) (envelope-from ) id 1cbxlO-000HNe-4l; Thu, 09 Feb 2017 23:04:30 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: ports and dependency hell From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= In-Reply-To: <34e34525-0e54-9033-270f-d1b9ddacd3db@freebsd.org> Date: Fri, 10 Feb 2017 00:04:27 +0100 Cc: Steve Wills , "ports@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1128C01F-C76E-470B-BF74-06480B08D8E7@waschbuesch.de> References: <11a62a44-1fef-0c58-da13-b024c28b4a5a@freebsd.org> <6e92ff1b-78ef-d6c2-83e7-059122977783@FreeBSD.org> <34e34525-0e54-9033-270f-d1b9ddacd3db@freebsd.org> To: Julian Elischer X-Mailer: Apple Mail (2.3259) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 23:04:34 -0000 > Am 09.02.2017 um 18:14 schrieb Julian Elischer : >=20 > Commercial products are Hardly EVER rolling releases. > they lurch from point of stability to point of stability, with large = amounts of testing between releases. >>> On the pkg side of things we need the ability for pkg to say "yeah I >>> know I'm looking for foo-1.2.3.txz as a perfect match, but I've been >>> given some slack on the third digit and I can see a foo-1.2.1.txz, = so >>> I'll install that instead". >> I'm not sure how you would do that in a general way that didn't add >> extra work for package maintainers. > pkg would have to do it looking in the pkg index. For every package depending on another as a building block, there are constraints as to which version (or range of versions) can satisfy the dependency. If more than one package depend on the same building blocks but (which is more likely than not) depend on different versions (or ranges of versions) of that package, the constraints become ever stricter, narrowing down the possible combinations. When installing just a limited few packages then maybe knowing about compatible ranges of versions of those packages would allow for more flexibility, but it does not sound practical at all: A specific version of package A can be compiled against all versions of library B v1.1, 1.2 or 1.3. Now, unless the exposed symbols where identical for all three versions, we would need to build a binary package for every combination of A and B. And we have not even considered what other versions of package A people might want to install... REALLY few packages and versions are needed before this becomes totally unfeasible. Now, as I see it, what pkg tries to do is for each snapshot to have as few conflicts as possible when you mix and match arbitrary packages by doing pkg install . I am not saying there are no conflicts, but the system and the package maintainers(!) do a great job of keeping packages both up to date and compatible to each other. You get that stability by not having a lot of choice where versions are concerned. But if you need more control over versions and package options, poudriere offers a very flexible way to create a customized (sub)set of pkgs tailored to your needs. Do the default pkg repo or poudriere cover all possible scenarios? No way! But I fail to understand how they could be expected to do that. Thus, what you describe sounds, imho, like wanting to eat the cake and have it. Martin=