In D1950#9, @rakuco wrote:

Personally, I'd commit the ALSA_EXTRA_PATCHES_OFF changes separately (and probably also backport them to the stable branch). I've also left some inline comments.

Except py-pykde4 everything looks fine. I'd like to review commit message as well.

I think Raphael meant patch which incorporates recent changes as well (I've committed two more). Could you renew the patch and propose commit message for it (see svn log for examples).

In D966#10, @bapt wrote:

CONFIGURE_ENV has to be seen has configure phase env not configure script env, and imho everything that needs ENV in configure phase should just use CONFIGURE_ENV instead of RANDOM_ENV imho it would be better to work on clarifying this than adding those new helpers.

In D1261#10, @alonso wrote:

Regenerate the patch to partially revert area51's revision 10488. While area51 doesn't use PORTREVISION,

We don't have strict rule not to use PORTREVISION in area51, it just isn't needed usually. kdevelop-pg-qt have not been updated upstream for a long time, we have the same version in the portstree and area51. So it makes sense to sync PORTREVISION as well when syncing other changes. Or we could remove the port from area51 at all, if new releases are unlikely.

devel/kdevelop-pg-qt is outdated in area51, sync it with portstree first. Other ports looks fine.

formally there are no conflicts currently: kdelibs depends on avahi-app only, it's avahi-libdns that conflicts with mDNSResponder. If you want change dependency from mDNSResponder to avahi-libdns, please do it for all ports at the same time.

Any comment? Should I consider the discussion closed?

In D1031#9, @rakuco wrote:

Avahi is used by some other ports, but in 2007 there were less Avahi users and therefore less chance to have Avahi installed and silently be used by kdelibs, so back then it might have been in use by more people.

Not really, unless I'm missing something obvious: since in addition to the dependency on net/avahi-libdns via the "AVAHI" option we've always depend on net/avahi-app, which contains the header that is used to detect Avahi's presence by kdelibs.

Note that removing MDNSRESPONSER wouldn't introduce a hard dependency on AVAHI, as kdelibs provides a dummy backend if no ZEROCONF backend is found.

The dummy backend is only built if neither mDNSResponder nor Avahi are found, but since we always depend on the port that provides the header used to check if Avahi is present or not, we'd still have a hard dependency on Avahi. This would only change if the dependency on net/avahi-app became optional.

In D1021#17, @rakuco wrote:

While looking at D1031, I looked at kdelibs's dnssd/CMakeLists.txt, and it appears to choose whether to use Avahi or mDNSResponder depending on whether the avahi-common/defs.h header is found. Since we always depend on net/avahi-app, in practice we haven't built the mDNSResponder code path in a very long time (if ever), even though we depend on the port...

Make sure the style of CMAKE_ARGS is consistent with the rest of the file (i.e. replace ON/OFF with On/Off). And don't bump PORTREVISION — there is no need for rebuilding the package.

In D1021#15, @rpaulo wrote:

I suppose it depends on how you use mDNSResponder, but it never worked reliably with IPv6 in my case, especially with temporary addresses. mDNSResponder also uses a custom binary format for queries in its UNIX domain socket, whereas avahi it's plain text. This makes it easier to build an nss library in the base system because it doesn't depend on anything 3rd party. The other reason is explained in the description:

mDNSResponder is unmaintained and was replaced by discoveryd. discoveryd is not open source yet and I don't know if it will ever be.

I would like to hear the reason for this change. Currently only three ports depend on avahi-libdns (and one of them the avahi meta port), while mDNSResponder is used by 25 ports + 450 kde ports via kdelibs. This change will cause package conflicts, particularly between kde ports and cups ports.

In D966#6, @mat wrote:

I'm with @antoine on this, both cmake and qmake replace configure, and both *_ENV already inherit from CONFIGURE_ENV.

I always thought it's by design, but I don't know if this is really needed for any port. Anyway [CQ]MAKE_ENV are already in use, so helpers for them would be nice to have.

looks ok.