From Newsgroup: muc.lists.freebsd.ports

Hi ports@!

Most probably the question was discussed a lot of times, but I have not found a definitive answer.

If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both libfoo and libbar?

Simple example (outdated, but the first thing you see in Porter's Handbook): games/oneko is linked with the command

cc -o oneko -L/usr/local/lib oneko.o -lXext -lX11 -lm -Wl,-rpath,/usr/local/lib

suggesting direct dependencies libXext and libX11. However, ldd oneko gives

libXext.so.6
libX11.so.6
libm.so.5
libc.so.7
libxcb.so.1
libthr.so.3
libsys.so.7
libXau.so.6
libXdmcp.so.6

Of course, libXau, libXdmcp, and libxcb are coming from libX11. The port

USES= imake xorg

Additionally, should it just depend on direct dependencies

USE_XORG= x11 xext

or the full dependency list?

USE_XORG= x11 xau xcb xdmcp xext

More complicated example: cad/freecad depends on cad/opencascade that depends on multimedia/ffmpeg4 with default options (can be switched off).

Should freecad port LIB_DEPENDS on ffmpeg4, as it is now, or should it track opencascade options, or should it not depend on ffmpeg4 at all?

Thank you in advance,
Alexey


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On 6/13/26 20:21, Bugs Beastie wrote:

Hi ports@!

Most probably the question was discussed a lot of times, but I have not found a definitive answer.

If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both libfoo and libbar?

Simple example (outdated, but the first thing you see in Porter's Handbook): games/oneko is linked with the command

cc -o oneko -L/usr/local/lib oneko.o -lXext -lX11 -lm -Wl,-rpath,/usr/local/lib

suggesting direct dependencies libXext and libX11. However, ldd oneko gives

libXext.so.6
libX11.so.6
libm.so.5
libc.so.7
libxcb.so.1
libthr.so.3
libsys.so.7
libXau.so.6
libXdmcp.so.6

Of course, libXau, libXdmcp, and libxcb are coming from libX11. The port

USES= imake xorg

Additionally, should it just depend on direct dependencies

USE_XORG= x11 xext

or the full dependency list?

USE_XORG= x11 xau xcb xdmcp xext

More complicated example: cad/freecad depends on cad/opencascade that depends on multimedia/ffmpeg4 with default options (can be switched off).

Should freecad port LIB_DEPENDS on ffmpeg4, as it is now, or should it track opencascade options, or should it not depend on ffmpeg4 at all?

Thank you in advance,
Alexey

In other words(?): Where does the responsibility for handling the
transitive closure of the dependencies reside?
--
===
Mark Millard
marklmi at yahoo.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Jun 14, 2026 06:07:18 Mark Millard <marklmi@yahoo.com>:

On 6/13/26 20:21, Bugs Beastie wrote:

Hi ports@!

Most probably the question was discussed a lot of times, but I have not found a definitive answer.

If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both libfoo and libbar?

Simple example (outdated, but the first thing you see in Porter's Handbook): games/oneko is linked with the command

cc -o oneko -L/usr/local/lib oneko.o -lXext -lX11 -lm -Wl,-rpath,/usr/local/lib

suggesting direct dependencies libXext and libX11. However, ldd oneko gives >>
libXext.so.6
libX11.so.6
libm.so.5
libc.so.7
libxcb.so.1
libthr.so.3
libsys.so.7
libXau.so.6
libXdmcp.so.6

Of course, libXau, libXdmcp, and libxcb are coming from libX11. The port

USES= imake xorg

Additionally, should it just depend on direct dependencies

USE_XORG= x11 xext

or the full dependency list?

USE_XORG= x11 xau xcb xdmcp xext

More complicated example: cad/freecad depends on cad/opencascade that depends on multimedia/ffmpeg4 with default options (can be switched off).

Should freecad port LIB_DEPENDS on ffmpeg4, as it is now, or should it track opencascade options, or should it not depend on ffmpeg4 at all?

Thank you in advance,
Alexey

In other words(?): Where does the responsibility for handling the
transitive closure of the dependencies reside?

Yes! More in the sense what is the current policy for the newly created ports?

I have a feeling that the answer changes over the time as the available infrastructure changes. I also think that both the current ports framework and pkg(-ng) can handle this transitive closure without manually unfolding the dependency tree in each port.

But let's wait for the answer of ports gurus!


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


On 14 Jun 2026, at 06:07, Mark Millard <marklmi@yahoo.com> wrote:

On 6/13/26 20:21, Bugs Beastie wrote:

[rCa.]
If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both libfoo and libbar?
[...]

In other words(?): Where does the responsibility for handling the
transitive closure of the dependencies reside?

Hi, from a principle point of view the port should add only libfoo unless it also uses directly libbar.
This because tomorrow morning the maintainer of libfoo might decide to stop using libbar and use libbaz instead, so your app does not need libbar anymore and dependency becomes implicitly:
app -> libfoo -> libbaz.
Just my two cents,
A.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports


--Apple-Mail=_1D97E3D3-C6F5-4E1A-B06A-7486C3BFEAAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8

On 14 Jun 2026, at 17:13, Mark Millard <marklmi@yahoo.com> wrote:

I would claim that the above effectively means that the responsibility
for indirect dependencies essentially needs to be split across the
automated build process and the automated installation process and, at
the scale involved, cannot reasonably/generally be handled at the =

source

code stage for tracking the indirect dependencies.

Hi,

I totally agree, this is why I think that (again: unless you *directly* =
use stuff from some sub-dependency, and then it=E2=80=99s not an =
indirect dependency, it=E2=80=99s a direct one) you should not manually = insert sub-dependencies in the port you maintain.

It=E2=80=99s already quite complex this way (especially when things like = python which has "it=E2=80=99s own dependency layer=E2=80=9D, or dbus =
which depends on it just for a small compile-time component get in=E2=80=A6=
), handling indirect dependencies in each port would be unaffordable =
IMHO.

But, as correctly said, let=E2=80=99s wait for the final statement from =
who knows more.

A.


--Apple-Mail=_1D97E3D3-C6F5-4E1A-B06A-7486C3BFEAAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">On 14 Jun 2026, at 17:13, Mark Millard = &lt;marklmi@yahoo.com&gt; wrote:<div><blockquote type=3D"cite"><div><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
24px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;">I would claim that the above effectively =
means that the responsibility</span><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 24px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
orphans: 2; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
24px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;">for indirect dependencies essentially needs =
to be split across the</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 24px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
orphans: 2; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
24px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;">automated build process and the automated = installation process and, at</span><br style=3D"caret-color: rgb(0, 0, =
0); font-family: Helvetica; font-size: 24px; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; =
orphans: 2; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
24px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;">the scale involved, cannot =
reasonably/generally be handled at the source</span><br =
style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
24px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration-line: none; = text-decoration-thickness: auto; text-decoration-style: solid;"><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
24px; font-style: normal; font-variant-caps: normal; font-weight: 400; = letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; =
display: inline !important;">code stage for tracking the indirect = dependencies.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 24px; font-style: normal; font-variant-caps: =
normal; font-weight: 400; letter-spacing: normal; orphans: 2; =
text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration-line: none; text-decoration-thickness: auto; = text-decoration-style: = solid;"></div></blockquote></div><br><div>Hi,</div><div><br></div><div>I = totally agree, this is why I think that (again: unless you *directly* =
use stuff from some sub-dependency, and then it=E2=80=99s not an =
indirect dependency, it=E2=80=99s a direct one) you should not manually = insert sub-dependencies in the port you = maintain.</div><div><br></div><div>It=E2=80=99s already quite complex =
this way (especially when things like python which has "it=E2=80=99s own = dependency layer=E2=80=9D, or dbus which depends on it just for a small = compile-time component get in=E2=80=A6), handling indirect dependencies =
in each port would be unaffordable IMHO.</div><div><br></div><div>But, =
as correctly said, let=E2=80=99s wait for the final statement from who =
knows =
more.</div><div><br></div><div>A.</div><div><br></div></body></html>=

--Apple-Mail=_1D97E3D3-C6F5-4E1A-B06A-7486C3BFEAAA--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Andrea Cocito wrote on Sun, 14 Jun 2026 16:32:11 +0200 (CEST):

On 6/13/26 20:21, Bugs Beastie wrote:

[....]
If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both libfoo and libbar?
[...]

In other words(?): Where does the responsibility for handling the transitive closure of the dependencies reside?

Hi, from a principle point of view the port should add only libfoo unless it also uses directly libbar.

This because tomorrow morning the maintainer of libfoo might decide to stop using libbar and use libbaz instead, so your app does not need libbar anymore and dependency becomes implicitly:
app -> libfoo -> libbaz.

Another scenario, highlighting the problems arising by adding indirect dependencies: Say, libfoo has an /alternate/ dependency (= configure
knob) on /either/ libbar /or/ libbaz. Would we really want to propagate
this alternate dependency (= configure knob) into the primary port
referencing libfoo, adding the same configure knob there as well? And
if we do that and have, for example, libfoo configured for the libbar dependency but the primary configured for the libbaz dependency - how
would we handle that conflict?

I have one example, and had a long and fruitless discussion with a
committer on such a scenario a while ago.

IMHO making indirect rependencies explicit is clearly evil.

Kind regards
Helge


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Bugs Beastie <bugsbeastie@gmail.com> writes:

Most probably the question was discussed a lot of times, but I have
not found a definitive answer.

If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both
libfoo and libbar?

If the app is only linked with libfoo, the port should only list libfoo
in LIB_DEPENDS.
As a practical matter, it is safe to err on the side of shorter
LIB_DEPENDS, because you will get an error if you should also have
included libbar but didn't.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

Jun 15, 2026 11:20:43 Dag-Erling Sm|+rgrav <des@FreeBSD.org>:

Bugs Beastie <bugsbeastie@gmail.com> writes:

Most probably the question was discussed a lot of times, but I have
not found a definitive answer.

If an app depends on libfoo that depends on libbar:
app -> libfoo -> libbar
Should the port of app add LIB_DEPENDS only on libfoo or on both
libfoo and libbar?

If the app is only linked with libfoo, the port should only list libfoo
in LIB_DEPENDS.

As a practical matter, it is safe to err on the side of shorter
LIB_DEPENDS, because you will get an error if you should also have
included libbar but didn't.

Thank you all for the answers!
We can summarize them in the Porter's Orange Bible:
"Thou The Port shalt not know the Ancestors of its Ancestors. Doing so is Heretek Omega and is sentenced to Immediate Death."
:)
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2