Poudriere builds have more dependencies than binary packages. Why?

E

Echoxxzz

I setup a poudriere server and I have not set any options for any ports and when I do a bulk build of net/samba413 it always includes the cyrus-sasl2 package as a dependency (among others) that are not required if I use the binary pre-built packages. This isn't the first time I've noticed this behavior of poudriere including a lot of extra dependencies that the binary packages or even a compile from a port directly don't include. My question is why does poudriere do this?
 
Echoxxzz said:
This isn't the first time I've noticed this behavior of poudriere including a lot of extra dependencies that the binary packages or even a compile from a port directly don't include.
Click to expand...
If you look on freshports.org you will notice there are build dependencies and runtime dependencies.
FreeBSD binary packages only require runtime dependencies.
I think you will find that FreeBSD ports and poudriere builds use the same build dependencies.
 
  • Like
Reactions: mtu
I'm only referring to runtime dependencies. For instance when I do a pkg install from the FreeBSD repo for Samba413 it doesn't install Cryus-SASL but when I install Samba413 from my poudriere server it does and I'm building everything using the same options that are used on Freshports.org.

They funny thing is if I install Samba413 from my poudriere server I can immediately remove cyrus-sasl without any complaints about breaking dependencies.
 
Perhaps the default configs are different? You explicitly say "...and I have not set any options for any ports..." Maybe the official package builds "don't do that"?
 
Echoxxzz said:
I'm only referring to runtime dependencies. For instance when I do a pkg install from the FreeBSD repo for Samba413 it doesn't install Cryus-SASL but when I install Samba413 from my poudriere server it does and I'm building everything using the same options that are used on Freshports.org.

They funny this if I install Samba413 from my poudriere server I can immediately remove cyrus-sasl without any complaints about breaking dependencies.
Click to expand...
Yeah, there seems to be a bug there. I get the same behavior with cyrus-sasl. Autoremove gets rid of it every time. There's some YAML library that gets pulled in uselessly too.
 
That makes sense since they both use the same makefile they should use the same dependencies.
I was thinking maybe different compiler options. I am unsure what flavors does differently as well.
 
Echoxxzz said:
I setup a poudriere server and I have not set any options for any ports and when I do a bulk build of net/samba413 it always includes the cyrus-sasl2 package as a dependency (among others) that are not required if I use the binary pre-built packages. This isn't the first time I've noticed this behavior of poudriere including a lot of extra dependencies that the binary packages or even a compile from a port directly don't include. My question is why does poudriere do this?
Click to expand...
They're probably indirect dependencies, or in other words, nested dependencies. Freshports.org and pkg info -d, and pkg info -r (pkg-info(8)) only list direct dependencies. olli@ has written a script to list nested dependencies recursively, which you can find here.

Run this script right after your bulk build, and before running pkg autoremove and I'm guessing it will probably show the dependencies.

Edited to add: Giving this some more thought, you'll need to be a bit more creative int tracing these dependencies, insofar as pkg info likely only traces runtime dependencies and not build dependencies, but I'm sure you get the idea.
 
The security/cyrus-sasl2 is likely to get pulled in if you build OpenLDAP with GSSAPI enabled. If you set WANT_OPENLDAP_SASL=yes in make.conf net/samba412 (413 likely too) is going to depend on net/openldap24-sasl-client instead of net/openldap24-client.

Poudriere might be confusing those options, or it might be a fault in the port, which could cause a dependency getting pulled in without it being registered as a dependency in that port. If it's automatically installed and nothing depends on it (due to the failure of the registration) then pkg-autoremove(8) would remove it again.

Vull said:
Giving this some more thought, you'll need to be a bit more creative int tracing these dependencies
Click to expand...
Yeah, hunting down dependency chain issues is a bit of a PITA.
 
Can't you use the make tools themselves?
/usr/ports/Mk/bsd.port.mk
Shows this: make BUILD_DEPENDS
Will make a list.
And various other iterations.
 
make run-depends-list and make build-depends-list are your friends. But you sometimes have to iterate through all the listed dependencies to get the entire chain. Port A depends on B which in turn depends on C, which depends on D, etc. It can be a bit of a pain to figure out which dependency is causing the issue.
 
Sort of like when you run make config-recursive you may need to run it more than once or you may get an option screen.
 
Yes, enabling or disabling options can significantly change the dependency chain, so you might need to rerun it a few times if you changed options.
 
I might be opening an already open door but poudriere takes care of everything.
For a very minimal number of ports I configure for instance - LDAPS , and everything compiles out of the box without any conflict and with all dependencies included. It has a drawback tough. A small change in one header file can make you force to rebuild hundreds of ports because of dependencies. But you are certain your system is stable.
I think the dependency graph of poudriere goes deeper and more thorough than for instance portmaster.
 
You must log in or register to reply here.
Back
Top