Re: configure path name of ebtables executable
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.