Re: Questions regarding BUILD_DEPENDS definition

On 12/04/2023 05:21, Matthias Fechner wrote:
> Am 11.04.2023 um 19:54 schrieb Matthew Seaman:
>> Hmmm... I wonder if this is the shared library provides/requires thing 
>> that pkg does?  If you run ldd(1) against the binaries from 
>> gitlab-shell, is there any indication of linking against a shlib from 
>> the heimdal port?
>>
>> If so, then that would seem to be a mistake in the gitlab-shell port, 
>> and it should probably add a LIB_DEPENDS against security/heimdal.
>>
>> Otherwise, all I can suggest is deleting both heimdal and gitlab-shell 
>> packages, and then reinstalling gitlab-shell. Hopefully that will tidy 
>> up the dependency graph.
> 
> I think that is it:

> $ ldd gitlab-sshd
> gitlab-sshd:
>          libgssapi.so.3 => /usr/local/lib/heimdal/libgssapi.so.3 
> (0x8012f2000)

> I'm not sure how to handle this.
> I saw in the commit logs that heimdal is only used if CGO is enabled in 
> the build. That could maybe be a work-around for this problem.

Thinking further about this, it shows pkg(8) is correctly and 
automatically deducing that gitlab-shell depends on heimdal shared 
libraries.  So everything gets installed correctly, and everything is 
functioning properly.

The problem at hand is that it isn't obvious from reading the port that 
this library dependnecy exists. Leading to confusion and a mismatch 
between expectation and actuality.

So a very simple solution might be the addition of 'USES+= 
heimdal:gssapi' as suggested by Tatsuki Makino.  Which is a perfect 
solution so long as it doesn't have much effect at all on the resulting 
build process and the generated packages compared to what we have right 
now.  Verifying that is just a matter of running some test builds and 
experimenting with the software.  In the unfortunate case that there are 
side effects then we'd have to think again.

There is a more subtle point here about freezing in specific package 
dependencies.  The shlibs provide/requires dependency just says 
'gitlab-shell needs the ABI provided by libgssapi.so.3' -- it's entirely 
agnostic about what other package provides that.  So if there were 
several different ports or port flavors providing libgssapi.so.3 you 
could switch between them easily, perhaps accomodating some other 
package you might have installed that needs a specific gssapi variant.

RUN_DEPENDS type dependencies on the other hand, wire things down: this 
port needs precisely the heimdal-7.8.0_6 port to be installed.  There's 
a built in assumption in pkg that you can come along later and update 
the heimdal package without breaking what depends on it. Or in other 
words the dependency is really on heimdal >= 7.8.0_6.  That may or may 
not be correct.  Being able to update dependent packages without 
breakage is only /usually/ true, but breakages due to that sort of 
change are sufficiently rare they can be handled as exceptions when they 
do occur.  Plus it precludes easily being able to use an alternate port 
like heimdal-devel.

The ports are actually quite good at expressing build-time dependencies 
needing particular version ranges, but that information doesn't get 
passed into the resulting pkgs.  Ports doesn't have an explicit 
mechanism for saying you could use one of a number of alternate packages 
to fulfil a dependency, but it does have an implicit feature like this. 
Saying RUN_DEPENDS+= go:lang/go120 means "install the lang/go120 package 
if there isn't a go binary on the path" but doesn't require that go 
binary to have come from the lang/go120 port.

What we generate nowadays as a run-time dependency should probably 
become more of a hint or a tie-breaker to pkg(8) to tell it what to 
default to installing when there aren't any other constraints.

	Cheers,

	Matthew