Re: [PATCH] configure: Check bzip2 is available

[Thomas Huth <thuth@redhat.com>]

On 08/11/2019 12.54, Philippe Mathieu-Daudé wrote:
> On 11/8/19 12:01 PM, Laszlo Ersek wrote:
>> On 11/08/19 11:28, Philippe Mathieu-Daudé wrote:
>>> The bzip2 tool is not included in default installations.
>>> On freshly installed systems, ./configure succeeds but 'make'
>>> might fail later:
>>>
>>>      BUNZIP2 pc-bios/edk2-i386-secure-code.fd.bz2
>>>    /bin/sh: bzip2: command not found
>>>    make: *** [Makefile:305: pc-bios/edk2-i386-secure-code.fd] Error 127
>>>    make: *** Deleting file 'pc-bios/edk2-i386-secure-code.fd'
>>>    make: *** Waiting for unfinished jobs....
>>>
>>> Add a check in ./configure to warn the user if bzip2 is missing.
>>
>> We've come full circle. Let me explain:
>>
>>>
>>> Fixes: 536d2173b2b
>>
>> So this makes me kinda grumpy. If you look at the v3 posting of the 
>> patch that would later become commit 536d2173b2b:
>>
>>    http://mid.mail-archive.com/20190321113408.19929-8-lersek@redhat.com
>>
>> you see the following note in the changelog:
>>
>>      - compress FD files with bzip2 rather than xz, so that 
>> decompression at
>>        "make install" time succeed on older build OSes too [Peter]
>>
>> So I couldn't use xz because that was "too new" for some build OSes, 
>> but now we also can't take bzip2 for granted because that's "too old" 
>> for some other build OSes? This is ridiculous.
>>
>> To be clear, my disagreement is only with the "Fixes" tag. For me, 
>> "Fixes" stands for something that, in retrospect, can be proven to 
>> have been a bug at the time the code was *originally* committed. But, 
>> at the time, taking "bzip2" for granted was *not* a bug. The 
>> conditions / circumstances have changed more recently, and the 
>> assumption about bzip2 has been invalidated *after* adding a 
>> dependency on bzip2.
>>
>> Nonetheless, thank you for adapting the code to the potential absence 
>> of bzip2. Can you perhaps go in some details in the commit message, 
>> near "not included in default installations" and "freshly installed 
>> systems"? If we can, we should identify the exact distro release where 
>> this problem has been encountered (and I wouldn't mind a link to the 
>> BZ or ticket under which people agreed to remove bzip2 from the 
>> default package set).
> 
> I am just reading this and already sent a v2.
> 
> I can amend these details. Thomas, what distro release were you using?

I encountered this problem with a freshly installed Fedora 31.

  Thomas