configure path name of ebtables executable

[Laine Stump]

On 11/17/21 4:52 PM, Michael Ströder wrote:
> On 11/17/21 20:28, Laine Stump wrote:
>> On 11/17/21 1:39 PM, Michael Ströder wrote:
>>> Is it possible to configure the full path name of the ebtables 
>>> executable used somewhere in libvirt's config?
>>
>> That's done in meson.build when you're building from source. Look for 
>> "optional_programs".
> 
> Noted. Thanks.
> 
>>> Background: I'd like to avoid automatic alternatives implementation 
>>> to mess up libvirt installation.
>>>
>>> See also:
>>> https://bugzilla.opensuse.org/show_bug.cgi?id=1192799
>>
>> I don't think the problem is what is being suggested in that bug.
> 
> Yes, it is.

The suggestion in that bug is that the problem is because "libvirt need 
/sbin/ebtables point to ebtables-legacy", which is definitely not the 
case. libvirt only requires that /sbin/ebtables point to a binary that 
correctly understands and acts on any valid ebtables command. If the 
binary pointed to by /sbin/ebtables doesn't do that, then it shouldn't 
be pointed to by /sbin/ebtables.

>> follow the symlink from /sbin/ebtables to (probably)
>> /etc/alternatives/ebtables > [..]
>> This sounds more like SUSE has some sort of special off-brand
>> alternative that doesn't understand all valid ebtables commands
> openSUSE Tumbleweed now uses libalternatives for ebtables (see my 
> comment#2) and thus
> /sbin/ebtables was linked to /usr/bin/alts. Yes, something's broken 
> there and I was looking for a work-around.
> 
>> Anyway, I think you'd be better off fixing the problem at the source
>> rather than trying to make some special local build of libvirt to
>> work around the problem.
> IMHO a libvirtd.conf option would be great to avoid relying on this 
> alternatives stuff.

There are many things within libvirt that we could do ourselves in order 
to avoid relying on some other package (or add a config knob to point at 
something different to do the work), but that just makes more code that 
must be maintained forever. Working around bugs in other packages with 
package-local fixes and config knobs is a never-ending unwinnable battle 
once you start, and leads to unnecessarily complicated code and 
technical debt (I say this from painful experience - although it's a bit 
of a whatabout-ism, if I had the time (I unfortunately don't :-)) I 
would tell the story of iptablesAddOutputFixUdpChecksum, just as one 
example).

I think a better road in this case (and most other cases) would be to 
fix the package that is broken (sounds like libalternatives). If it is 
breaking libvirt, it's likely breaking other things as well.