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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludo,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi Ludovic,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi!
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> 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>.

I've been building a sizable part of core-updates on top of this change
now for nearly two weeks, and in this time it's already come handy
twice.

I've made sure the tests ran fine and pushed to core-updates as commit
cfcead2e515c0dae02127e5a76496463898be6b6.

Let me know if anything breaks :-).

Maxim