Date: Fri, 10 Feb 2017 00:04:27 +0100 From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= <martin@waschbuesch.de> To: Julian Elischer <julian@freebsd.org> Cc: Steve Wills <swills@FreeBSD.org>, "ports@FreeBSD.org" <ports@freebsd.org> Subject: Re: ports and dependency hell Message-ID: <1128C01F-C76E-470B-BF74-06480B08D8E7@waschbuesch.de> In-Reply-To: <34e34525-0e54-9033-270f-d1b9ddacd3db@freebsd.org> References: <11a62a44-1fef-0c58-da13-b024c28b4a5a@freebsd.org> <6e92ff1b-78ef-d6c2-83e7-059122977783@FreeBSD.org> <34e34525-0e54-9033-270f-d1b9ddacd3db@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Am 09.02.2017 um 18:14 schrieb Julian Elischer <julian@freebsd.org>: >=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 <software1> <lib2> <app3>. 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1128C01F-C76E-470B-BF74-06480B08D8E7>