[PATCH] storage: fix vstorage backend build

[Andrea Bolognani]

On Mon, 2020-07-13 at 11:52 +0300, Nikolay Shirokovskiy wrote:
> On 13.07.2020 09:57, Nikolay Shirokovskiy wrote:
> > On 10.07.2020 21:17, Andrea Bolognani wrote:
> > > If you look at the list of packages through the provided "repoview"
> > > files, the releases from the second repository contain many more:
> > > additional categories include things like "Readykernel", Virtuozzo
> > > High Availability" and, most interesting to us, "Virtuozzo Storage".
> > > 
> > > As mentioned in my previous message, some of these packages appear to
> > > be released not under the (L)GPL but under a "Virtuozzo" license that
> > > I haven't been able to find anywhere, and I'm not entirely sure is
> > > actually open source.
> > 
> > We have Virtuozzo product and part of it is available as open source
> > from openvz.org repo. Virtuozzo Storage is not open source but it
> > can be used with very limited storage size without license keys.
> > I guess you would want to read license anyway before using Virtuozzo
> > Storage packages in CI but I'm going to remove these packages
> > requirements anyway as I wrote in reply to Andrea's message.
> 
> After giving it more thought I think it is useful to have vstorage
> m4 script as it is. It is useful to detect vstorage-mount binary
> path at build time. Although Virtuozzo Storage is not open source
> and can not be build for distributions with different binary paths
> by community it is a part of different Virtuozzo products and
> theoretically speaking the path can be changed from product to product.
> So it is useful to have path not hardcoded and not detected at runtime.

If runtime detection is good enough for qemu-img, I don't see why it
wouldn't be good enough for vstorage too.

> Before we fix our repos please take a look at Virtuozzo license at [1]
> (note there is different tabs and EULA tab).
> 
> [1] https://www.virtuozzo.com/legal.html

Yeah, sorry, but I'm not going to put my name on a patch that results
in our build environments suddenly including proprietary software.
I'm already not a fan that happening based on principles alone, and I
most certainly don't want to deal with any potential fallout from our
container images violating the EULA or whatnot.

-- 
Andrea Bolognani / Red Hat / Virtualization