Hi Julien,

On Thu, Jan 13, 2011 at 12:18:49PM +0100, Julien BLACHE wrote:
> > This is fine with me, but shouldn't we instead use a virtual package such as
> > (the currently not yet existing package) 'multicast-routing-daemon' that 
> > both
> 
> smcroute is *NOT* a multicast routing daemon :)
> 
> A multicast routing daemon is a daemon that manages the multicast
> routing table dynamically based on IGMPv3 signalling.

Speaking about real multicast routing you're right and I totally agree that
smcroute is *not* a multicast routing daemon in this sense.

But from the point of view of the kernel smcroute claims that it *is* a
multicast routing daemon by calling setsockopt() with MRT_INIT or MRT6_INIT.
And exactly this setsockopt() call is the reason why you cannot start another
(or a real) multicast routing daemon when smcroute is running: The kernel by
design refuses to setsockopt() with MRT_INIT on another socket as long as the
previous MRT_INIT-ialized socket is still open.

Thus I maintain my suggestion to add Provides:/Conflicts: dependencies to a
virtual package (e.g. 'multicast-routing-daemon', but feel free to suggest
another name).

> The proper thing to do here is to demote smcroute to Priority: extra and
> leave pimd at Priority: optional.

This would be fine with me as well.

> The pimd/xorp situation should be investigated, as I'm not sure both can
> be installed at the same time either.

They cannot because multicast routing always needs access to the multicast
routing table (MRT), which the kernel lets you only access through a socket
after calling setsockopt() with MRT_INIT (see above).

Regards,
Micha



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to