Bug 243678 - net/dhcpcd: fails packaging with custom src.conf options set
Summary: net/dhcpcd: fails packaging with custom src.conf options set
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Depends on:
Reported: 2020-01-28 19:41 UTC by Dries Michiels
Modified: 2021-05-22 02:22 UTC (History)
4 users (show)

See Also:

net-dhcpcd.log (24.95 KB, text/plain)
2020-01-28 19:41 UTC, Dries Michiels
no flags Details
dhcpcd.diff (1.68 KB, patch)
2020-02-25 20:36 UTC, Dries Michiels
no flags Details | Diff
Allow --with-eghook=ypbind (1.71 KB, patch)
2020-06-17 14:16 UTC, roy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dries Michiels 2020-01-28 19:41:48 UTC
Created attachment 211140 [details]


In attachments you can find the complete build log of dhcpcd on my STABLE-12 system. I have set multiple src.conf options such as WITHOUT_NIS= which results in not building and installing those binaries/headers for my base systemt. This results in dhcpcd not detecting the program and thus not installing 50-ypbind while it is statically included in its port. https://github.com/rsmarples/dhcpcd/blob/master/configure (line 1646)

A similar problem will arise when WITHOUT_NTP= is set in src.conf option with the 50-ntp.conf file.

I see two solutions: 

1) Install all hooks independent of the base system configuration (eg in post-install copying all scripts manually). Since this does not influence the binary itself but only the hooks, I think this is easiest. Even if NTP or NIS are not present in the base system the installed hooks wont cause any havoc.

2) Be able to give flags from the ports infrastructure to the dhcpcd build to force each of them on or off. Then the port logic can deal with the pkg-plist dynamic nature.

Thoughts? Happy to provide a patch for 1). From a quick scan I don't think 2) Is possible with the current configure of dhcpcd.
Comment 1 roy 2020-01-28 20:51:06 UTC
I don't think NIS is used much anymore really.
In pkgsrc we just hardcode the ntp.conf hook as it's extremely portable:

CONFIGURE_ARGS+=        --with-hooks=ntp

Or you could make the hooks optional and set pass an array via --withhooks="hook1 hook2" or one by one --withhook=hook1 --withhook=hook2 and toggle each hook via the ports option menu thingy which I have no idea how to do.
Comment 2 Dries Michiels 2020-02-25 20:36:59 UTC
Created attachment 211939 [details]

This forces the install of the ntp hook independent if ntpd is installed or not. Also force ypbind script to not be installed (excluded from pkg-plist). Roy, I could not force ypbind to be installed by using --with-hook=ypbind like I could with --with-hook=ntp, or is the naming incorrectly of my configure args?
Comment 3 roy 2020-06-17 14:16:47 UTC
Created attachment 215658 [details]
Allow --with-eghook=ypbind

For FreeBSD this is fine as no special vars to create the ypbind hook script are needed.

Sorry this slipped of my radar.
Comment 4 roy 2020-06-17 14:19:06 UTC
This wil appear quite soon in dhcpcd-9.1.3, so might want to wait until the weekend.
Comment 5 Dries Michiels 2020-06-17 19:22:22 UTC
Thanks for picking this up again Roy, what will the change upstream result in here? Will we have to manually enable eghooks like ypbind? Meaning by default it wont install ypbind.conf?
Comment 6 roy 2020-06-17 19:33:28 UTC
In this case you'll need to manually specify the hook.
ypbind is tailored for each distro during configure presently.
FreeBSD enjoys the luxury of nothing special needed to be set, so just enabling the hook is fine.
Comment 7 Volodymyr Kostyrko 2021-02-05 12:46:29 UTC
+1, failed on missing 50-ypbind that is mentioned in pkg-plist
Comment 8 roy 2021-02-05 14:10:06 UTC
I recently made an upstream change as a result of the import review here:

So even if ypbind is not present on the target system, if the host is FreeBSD the example hook will be correctly built and installed as an example.
This will be in the next release.
Comment 9 Ben Woods freebsd_committer 2021-05-22 02:22:13 UTC
Sorry, due to a lack of time I have reset the maintainer of this port back to ports@FreeBSD.org. Hopefully someone else is able to step in to help.
Resetting the assignee of this bug accordingly.