Patchwork zeroconf: remove

login
register
mail settings
Submitter Paul Eggleton
Date Aug. 22, 2012, 3:50 p.m.
Message ID <1345650627-3232-1-git-send-email-paul.eggleton@linux.intel.com>
Download mbox | patch
Permalink /patch/35141/
State Accepted
Commit 88b4ec0b8c7c75b8570fc201c705937b459bb43e
Headers show

Comments

Paul Eggleton - Aug. 22, 2012, 3:50 p.m.
We already have avahi in OE-Core and some cursory research suggests that
avahi is preferred over this package, which has apparently not seen a
release since 2006. Nothing in OE-Core actually refers to it, so let's just
remove it.

CC: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 .../zeroconf/zeroconf/compilefix.patch             |   19 --------
 .../zeroconf/zeroconf/debian-zeroconf              |   51 --------------------
 .../zeroconf/zeroconf/zeroconf-default             |   17 -------
 meta/recipes-connectivity/zeroconf/zeroconf_0.9.bb |   34 -------------
 4 files changed, 121 deletions(-)
 delete mode 100644 meta/recipes-connectivity/zeroconf/zeroconf/compilefix.patch
 delete mode 100644 meta/recipes-connectivity/zeroconf/zeroconf/debian-zeroconf
 delete mode 100644 meta/recipes-connectivity/zeroconf/zeroconf/zeroconf-default
 delete mode 100644 meta/recipes-connectivity/zeroconf/zeroconf_0.9.bb
Paul Eggleton - Aug. 22, 2012, 4:11 p.m.
On Wednesday 22 August 2012 16:50:27 Paul Eggleton wrote:
> We already have avahi in OE-Core and some cursory research suggests that
> avahi is preferred over this package, which has apparently not seen a
> release since 2006. Nothing in OE-Core actually refers to it, so let's just
> remove it.

Hmm, this was meant to be an RFC - I would like to give people some time to 
respond.

Cheers,
Paul
Ross Burton - Aug. 22, 2012, 4:25 p.m.
On 22 August 2012 17:11, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> On Wednesday 22 August 2012 16:50:27 Paul Eggleton wrote:
>> We already have avahi in OE-Core and some cursory research suggests that
>> avahi is preferred over this package, which has apparently not seen a
>> release since 2006. Nothing in OE-Core actually refers to it, so let's just
>> remove it.
>
> Hmm, this was meant to be an RFC - I would like to give people some time to
> respond.

Not seeing a release since 2006 is good enough reason to remove
something which is handling data directly from the network...

Ross
Koen Kooi - Aug. 22, 2012, 4:32 p.m.
Op 22 aug. 2012, om 18:11 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Wednesday 22 August 2012 16:50:27 Paul Eggleton wrote:
>> We already have avahi in OE-Core and some cursory research suggests that
>> avahi is preferred over this package, which has apparently not seen a
>> release since 2006. Nothing in OE-Core actually refers to it, so let's just
>> remove it.
> 
> Hmm, this was meant to be an RFC - I would like to give people some time to 
> respond.

IIRC gumstix used it for bonjour without bringing in the megabytes of support needed for avahi.
Richard Purdie - Aug. 22, 2012, 4:40 p.m.
On Wed, 2012-08-22 at 18:32 +0200, Koen Kooi wrote:
> Op 22 aug. 2012, om 18:11 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:
> 
> > On Wednesday 22 August 2012 16:50:27 Paul Eggleton wrote:
> >> We already have avahi in OE-Core and some cursory research suggests that
> >> avahi is preferred over this package, which has apparently not seen a
> >> release since 2006. Nothing in OE-Core actually refers to it, so let's just
> >> remove it.
> > 
> > Hmm, this was meant to be an RFC - I would like to give people some time to 
> > respond.
> 
> IIRC gumstix used it for bonjour without bringing in the megabytes of
> support needed for avahi.

I'm not sure that is enough to warrant it staying in OE-Core. meta-oe
might be a better fit? Can avahi be cut down for "tiny" usage though
configuration?

Cheers,

Richard
Paul Eggleton - Aug. 22, 2012, 4:43 p.m.
On Wednesday 22 August 2012 18:32:46 Koen Kooi wrote:
> IIRC gumstix used it for bonjour without bringing in the megabytes of
> support needed for avahi.

FWIW, meta-gumstix of today has no reference to it; but on the other hand it 
is a BSP layer with no tasks or recipes.

Cheers,
Paul
Ross Burton - Aug. 22, 2012, 4:44 p.m.
> I'm not sure that is enough to warrant it staying in OE-Core. meta-oe
> might be a better fit? Can avahi be cut down for "tiny" usage though
> configuration?

Agreed.

I don't think Avahi can be cut down enough, zerconf only supports
exposing the machine name which is a pretty tiny subset of mDNS in
total.

ross
Paul Eggleton - Sept. 3, 2012, 1:47 p.m.
On Wednesday 22 August 2012 17:44:14 Burton, Ross wrote:
> > I'm not sure that is enough to warrant it staying in OE-Core. meta-oe
> > might be a better fit? Can avahi be cut down for "tiny" usage though
> > configuration?
> 
> Agreed.
> 
> I don't think Avahi can be cut down enough, zerconf only supports
> exposing the machine name which is a pretty tiny subset of mDNS in
> total.

So, where does that leave us with this patch then?

Cheers,
Paul
Ross Burton - Sept. 3, 2012, 1:53 p.m.
On 3 September 2012 14:47, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> So, where does that leave us with this patch then?

I'd say merge it, if anyone really needs a tiny mDNS responder they
can dig it out.

Ross
Koen Kooi - Sept. 3, 2012, 2:05 p.m.
Op 3 sep. 2012, om 15:53 heeft "Burton, Ross" <ross.burton@intel.com> het volgende geschreven:

> On 3 September 2012 14:47, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
>> So, where does that leave us with this patch then?
> 
> I'd say merge it, if anyone really needs a tiny mDNS responder they
> can dig it out.

And put it in meta-networking instead of oe-core :)
Ross Burton - Sept. 3, 2012, 2:13 p.m.
On 3 September 2012 15:05, Koen Kooi <koen@dominion.thruhere.net> wrote:
> And put it in meta-networking instead of oe-core :)

Yay another dumping around! It's so nice having multiple dumping
grounds to pick from.

Ross
Paul Eggleton - Sept. 3, 2012, 2:22 p.m.
On Monday 03 September 2012 15:13:10 Burton, Ross wrote:
> On 3 September 2012 15:05, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > And put it in meta-networking instead of oe-core :)
> 
> Yay another dumping around! It's so nice having multiple dumping
> grounds to pick from.

Well, to be fair the intent is that meta-networking should be fairly well-
organised. The only issue with this specific recipe is that the upstream is 
unmaintained.

Cheers,
Paul

Patch

diff --git a/meta/recipes-connectivity/zeroconf/zeroconf/compilefix.patch b/meta/recipes-connectivity/zeroconf/zeroconf/compilefix.patch
deleted file mode 100644
index 328e574..0000000
--- a/meta/recipes-connectivity/zeroconf/zeroconf/compilefix.patch
+++ /dev/null
@@ -1,19 +0,0 @@ 
-| zeroconf.c: In function 'main':
-| zeroconf.c:145: error: 'PATH_MAX' undeclared (first use in this function)
-
-RP - 4/9/09
-
-Upstream-Status: Pending
-
-Index: zeroconf-0.9/zeroconf.c
-===================================================================
---- zeroconf-0.9.orig/zeroconf.c	2009-09-04 10:05:25.000000000 +0100
-+++ zeroconf-0.9/zeroconf.c	2009-09-04 10:05:42.000000000 +0100
-@@ -33,6 +33,7 @@
- #include <net/if_arp.h>
- #include <sys/time.h>
- #include <signal.h>
-+#include <limits.h>
- 
- #include "delay.h"
- 
diff --git a/meta/recipes-connectivity/zeroconf/zeroconf/debian-zeroconf b/meta/recipes-connectivity/zeroconf/zeroconf/debian-zeroconf
deleted file mode 100644
index c3705d2..0000000
--- a/meta/recipes-connectivity/zeroconf/zeroconf/debian-zeroconf
+++ /dev/null
@@ -1,51 +0,0 @@ 
-#!/bin/sh
-
-if [ ! -x /usr/sbin/zeroconf ]; then
-    exit 0
-fi
-
-# IPv4 link-local addresses (zeroconf) are
-# only applicable on the 'inet' address family
-[ "X$ADDRFAM" != "Xinet" ] && exit 0
-
-# However there are some methods where it doesn't
-# make any sense to configure an IPv4LL address
-
-# not on loopback
-[ "X$METHOD" = "Xloopback" ] && exit 0
-
-# not on ppp or wvdial either
-[ "X$METHOD" = "Xppp" ] && exit 0
-[ "X$METHOD" = "Xwvdial" ] && exit 0
-
-# The administrator may have blacklisted interfaces
-# or only want zeroconf in a fallback situation
-[ -f /etc/default/zeroconf ] &&
-    . /etc/default/zeroconf
-
-[ -n "$DISABLE" ] && exit 0
-
-for BLACK in $IFBLACKLIST; do
-    case $IFACE in
-	$BLACK)
-	exit 0
-	;;
-    esac
-done
-
-# should we only allocate an address if we do not already have one?
-if [ -n "$FALLBACK" ]; then
-    /bin/ip addr show $IFACE scope global | grep -q "inet"
-    IP=$?
-    if [ $IP -eq 0 ]; then
-        /bin/ip route add 169.254.0.0/16 dev $IFACE
-        exit 0
-    fi
-fi
-
-# otherwise, run if we aren't already going
-if [ ! -r /var/run/zeroconf.$IFACE.pid ]; then
-	/usr/sbin/zeroconf -i $IFACE
-fi
-
-exit 0
diff --git a/meta/recipes-connectivity/zeroconf/zeroconf/zeroconf-default b/meta/recipes-connectivity/zeroconf/zeroconf/zeroconf-default
deleted file mode 100644
index cc07b27..0000000
--- a/meta/recipes-connectivity/zeroconf/zeroconf/zeroconf-default
+++ /dev/null
@@ -1,17 +0,0 @@ 
-# Default for zeroconf
-
-# disable zeroconf
-# If you want to disable zeroconf completely, uncomment the following line
-# this may be useful if you are debugging zeroconf or starting it manually
-#DISABLE=yes
-
-# black-listed interfaces
-# Interfaces which you never wish to have zeroconf run on should
-# be listed here. e.g. "eth2 wlan1" in a space seperated string
-IFBLACKLIST=""
-
-# fallback only
-# If you would only like a link-local address if you were unable to
-# obtain an address via DHCP then uncomment the following line
-#FALLBACK=yes
-
diff --git a/meta/recipes-connectivity/zeroconf/zeroconf_0.9.bb b/meta/recipes-connectivity/zeroconf/zeroconf_0.9.bb
deleted file mode 100644
index f755940..0000000
--- a/meta/recipes-connectivity/zeroconf/zeroconf_0.9.bb
+++ /dev/null
@@ -1,34 +0,0 @@ 
-SUMMARY = "IPv4 link-local address allocator"
-DESCRIPTION = "Zeroconf is a program that is used to claim IPv4 \
-link-local addresses. IPv4 link-local addresses are useful when setting \
-up ad-hoc networking between devices without the involvement of a either \
-a DHCP server or network administrator. \
-These addresses are allocated from the 169.254.0.0/16 address range and \
-are normally attached to each Ethernet device in your computer. \
-Addresses are assigned randomly by each host and, in case of collision, \
-both hosts (are supposed to) renumber."
-AUTHOR = "Anand Kumria <wildfire@progsoc.uts.edu.au>"
-HOMEPAGE = "http://www.progsoc.org/~wildfire/zeroconf/"
-LICENSE = "GPLv2+"
-LIC_FILES_CHKSUM = "file://COPYING;md5=4325afd396febcb659c36b49533135d4 \
-                    file://zeroconf.c;beginline=1;endline=13;md5=a5bada96e1e34b08eb7446b28e2630b2"
-SECTION = "net"
-
-PR = "r1"
-
-SRC_URI = "http://www.progsoc.org/~wildfire/zeroconf/download/${BPN}-${PV}.tar.gz \
-           file://compilefix.patch \
-           file://zeroconf-default \
-           file://debian-zeroconf"
-
-SRC_URI[md5sum] = "bdafb16b008ebb5633e4e581f77821d2"
-SRC_URI[sha256sum] = "a8c74df127753e2310fa1e072f3c9ca44a404bb0bbce9cfec7a84c6dff8bec7b"
-
-do_install () {
-	install -d ${D}${sbindir}
-	install -d ${D}${sysconfdir}/network/if-up.d
-	install -d ${D}${sysconfdir}/default
-	install -c -m 755 ${S}/zeroconf ${D}${sbindir}/zeroconf
-	install -c -m 755 ${WORKDIR}/debian-zeroconf ${D}${sysconfdir}/network/if-up.d/zeroconf
-	install -c ${WORKDIR}/zeroconf-default ${D}${sysconfdir}/default/zeroconf
-}