On Mon, 2018-10-08 at 13:10 +0200, Peter Krempa wrote:
> On Mon, Oct 08, 2018 at 13:04:17 +0200, Andrea Bolognani wrote:
> > On Mon, 2018-10-08 at 12:59 +0200, Peter Krempa wrote:
> > > Well, if we are going to bend the rules and make a hack for the mess
> > > some downstream distro made, then we should keep the original code which
> > > allows to add mess for other distros as well.
> >
> > The downstream path names I dropped are no longer necessary because
> > Debian and friends are using the standard binary names in all
> > releases we support; the same is not true of RHEL, which is why that
> > one path has not been removed along with the rest.
>
> That is perfectly fine with me. I'm arguing that we should keep the
> whole function that iterates the array of override paths even if it
> contains the exception only for RHEL.
>
> Doing a tailored special case for RHEL seems like we are favoriting it
> somehow which we should not. So either the loop is deleted without
> replacement and RHEL maintainers fix their mess or we keep it as-is so
> that other distros can add their mess as well.
I don't expect distros that have gotten rid of their own incompatible
binary names (eg. all except RHEL) will reintroduce them, so the loop
would be needlessly verbose dead code right now and most likely going
forward.
If anyone will seriously accuse us of "favoring RHEL" because of how
that piece of code is written, we can just point at the git history
and show them that it was simply the most concise way to achieve its
goal given the known constraints.
Of course if at any point down the line I'm proven wrong about the
assumption described above and we end up needing to special-case
another binary name, then reintroducing the loop will be the correct
solution.
tl;dr I stand behind my changes and won't support reverting them
unless a purely technical need motivates doing so.
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
