[PATCH] storage: fix vstorage backend build

[Nikolay Shirokovskiy]

On 13.07.2020 12:16, Andrea Bolognani wrote:
> 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.
> 

Ok, given all the license stuff and the fact we can just use runtime
binary detection let's go with this variant. I'll send the patch.

Nikolay