cups-base seems not to build unless you select MDNSRESPONDER
Created attachment 151744 [details] poudriere logfile with Avahi selcted
Created attachment 151745 [details] poudriere logfile with neither avahi nor mdnsresponder selected
I did some investigating on this. The problem still exists and seems to surface when print/cups-base and print/cups-client have different options selected for Zeroconf support. For example if cups-base uses AVAHI and cups-client uses MDNSRESPONDER compilation will fail. I'm unsure how this can be fixed. The split of cups into cups-base, cups-client, cups-image makes this harder than it has to be.
Also see bug #203053.
(In reply to Tobias Kortkamp from comment #3) > I did some investigating on this. The problem still exists and seems to > surface when print/cups-base and print/cups-client have different options > selected for Zeroconf support. For example if cups-base uses AVAHI and > cups-client uses MDNSRESPONDER compilation will fail. I'm unsure how this > can be fixed. The split of cups into cups-base, cups-client, cups-image > makes this harder than it has to be. Shouldn't all the cups-* be children of print/cups-base ? eg; MASTERDIR?= ${.CURDIR}/../cups-base Where name/connection resolution options are *only* possible via it's master/parent: print/cups-base ? I'm sure that this route would prevent conflicting (M)OPTION choices. No? Just my 0.2¢ on the matter. :) --Chris
(In reply to Chris Hutchinson from comment #5) They all have MASTERDIR set. Here's what I tried: 1. I've rmconfig'ed both cups-client and cups-base. 2. Then I enabled the AVAHI option in cups-base 3. Now cups-client and cups-base have conflicting options selected. Is MASTERDIR supposed to enable some kind of magic that prevents this from happening? What I would expect is for both of them to have AVAHI=on now (i.e. that cups-base dictates the options for cups-client). I also would expect make -C cups-client config to tell me that I need to configure cups-base instead and not present the option dialog at all. $ make -C /usr/ports/print/cups-client showconfig ===> The following configuration options are available for cups-client-2.0.3_2: ====> Zeroconf support: you can only select none or one of them AVAHI=off: Zeroconf support via Avahi MDNSRESPONDER=on: Zeroconf support via mDNSResponder ===> Use 'make config' to modify these settings $ make -C /usr/ports/print/cups-base showconfig ===> The following configuration options are available for cups-base-2.0.3_6: [...] ====> Zeroconf support: you can only select none or one of them AVAHI=on: Zeroconf support via Avahi MDNSRESPONDER=off: Zeroconf support via mDNSResponder ===> Use 'make config' to modify these settings
(In reply to Tobias Kortkamp from comment #6) > (In reply to Chris Hutchinson from comment #5) > They all have MASTERDIR set. Here's what I tried: > > 1. I've rmconfig'ed both cups-client and cups-base. > 2. Then I enabled the AVAHI option in cups-base > 3. Now cups-client and cups-base have conflicting options selected. > Is MASTERDIR supposed to enable some kind of magic that prevents this from > happening? Well. That's the (intended?) logic from my experience. While I do have a couple of 9-STABLE boxes; I'm writing this from a -CURRENT (11) box. So I'm using that ports tree for reference(s). I only mention that, as I notice you appear to be talking about 9.(3?) given your attached log(s). I see there's an entry in UPDATING about cups-client / cups-image, but it's dated 20140331. So I can't imagine it applies to you. Looking at the print/cups-base/Makefile nothing jumps out at me to lead me to think it would generate more than *one* set of [*dns*] options. You don't have anything in your make.conf(5) that might pollute your environment, do you? Just a thought. --Chris
Since ports r410825 the MDNSRESPONDER option has been removed so this should no longer be a problem.