ports and dependency hell

[Martin Waschbüsch]

> Am 09.02.2017 um 18:14 schrieb Julian Elischer <julian at freebsd.org>:
> 
> 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