Subject: [bug#45774] bug#45773: [PATCH core-updates 0/1] Allow patch-and-repack to work with plain files.

From: Maxim Cournoyer <[email-masked]>
Date: Thu, 14 Jan 2021 13:43:43 -0500

Hi Ludovic,

Ludovic Courtès <[email-masked]> writes:

> Hi!
>
> Maxim Cournoyer <[email-masked]> skribis:
>
>> Before this change, only plain directories, tar or zip archives were supported
>> as the source of a package for the GNU build system; anything else would cause
>> the unpack phase to fail.  Origins relying on snippets would suffer from the
>> same problem.
>>
>> This change adds the support to use files of the following extensions: .gz,
>> .Z, .bz2, .lz, and .xz, even when they are not tarballs.  Files of unknown
>> extensions are treated as uncompressed files and supported as well.
>>
>> * guix/packages.scm (patch-and-repack): Only add the compressor utility to the
>> PATH when the file is compressed.  Bind more inputs in the mlet, and use them
>> for decompressing single files.  Adjust decompression and compression routines.
>> [decompression-type]: Return #f when no known compression extension is used.
>> [tarball?]: New nested procedure.
>> * guix/build/utils.scm (compressor, tarball?): New procedures.  Move
>> %xz-parallel-args to the new 'compression helpers' section.
>> * tests/packages.scm: Add tests.  Add missing copyright year for Jan.
>> * guix/build/gnu-build-system.scm (first-subdirectory): Return #f when no
>> sub-directory was found.
>> (unpack): Support more file types, including uncompressed plain files.
>> ---
>>  guix/build/gnu-build-system.scm |  24 ++++++--
>>  guix/build/utils.scm            |  47 ++++++++++-----
>>  guix/packages.scm               | 100 +++++++++++++++++---------------
>>  guix/tests.scm                  |  40 ++++++++++++-
>>  tests/builders.scm              |  40 ++++++++++++-
>>  tests/packages.scm              |  69 +++++++++++++++++++++-
>>  6 files changed, 247 insertions(+), 73 deletions(-)
>
> How frequent is it for an origin to be a regular file other than an
> archive?  The underlying question for me is: will this generalization
> and increased complexity pay off?  WDYT?

I think consistency is the main driver here.  The url-fetch method
supports single file sources; it makes sense that the other components
handling sources support it as well.  It's hard to judge of the
popularity of such a feature when it's never been available; but some
use cases come to mind such as single Emacs package file.  I've made use
of such feature for the new texlive-updmap.cfg definition in
<http://issues.guix.gnu.org/45870>.

> There are aspects of the patch that I find welcome regardless, such as
> the improved handling of compression helpers.

Great!  Thanks for looking at it.

Maxim