proposal: modularize unpack in gnu build system

proposal: modularize unpack in gnu build system

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 684 bytes --]

It seems, that currently we don't have zip in gnu build system, so that
ends up in native-inputs, if we need that to unpack the tarball.

It would be nice if gnu-build-system would use the appropriate compressor,
and at the same time only depend on the one needed. How could this be
achieved?

We already do something like this when specifying the source of a package.

I guess that something like we are using now structured as download,
git-download, snv-download.
It could go like tar-unpack, zip-unpack and more. What seem to be more
intresting in this case, that we should guess the one we should use, and
lazily evaluate, so that we don"t end up depending on all possibilities.

[-- Attachment #2: Type: text/html, Size: 797 bytes --]

Re: proposal: modularize unpack in gnu build system

[Ricardo Wurmus]

Gábor Boskovits <boskovits@gmail.com> writes:

> It seems, that currently we don't have zip in gnu build system, so that
> ends up in native-inputs, if we need that to unpack the tarball.
>
> It would be nice if gnu-build-system would use the appropriate compressor,
> and at the same time only depend on the one needed. How could this be
> achieved?

Why is this necessary?  I don’t see a problem with adding “unzip” to the
native-inputs when it is needed to unpack a zip archive.

In my opinion this is so easy that I don’t think the slight increase in
convenience would be worth the change.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: proposal: modularize unpack in gnu build system

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

2018-02-11 22:50 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Gábor Boskovits <boskovits@gmail.com> writes:
>
> > It seems, that currently we don't have zip in gnu build system, so that
> > ends up in native-inputs, if we need that to unpack the tarball.
> >
> > It would be nice if gnu-build-system would use the appropriate
> compressor,
> > and at the same time only depend on the one needed. How could this be
> > achieved?
>
> Why is this necessary?  I don’t see a problem with adding “unzip” to the
> native-inputs when it is needed to unpack a zip archive.
>
> In my opinion this is so easy that I don’t think the slight increase in
> convenience would be worth the change.
>
>
You might be right about that. What I feel is that:
1. this is a recurring newbie question on the irc channel, I've seen it
already a few times, so support time could be reduced
2. this change could make adding new archive types easier in the future.


> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net
>
>
>

[-- Attachment #2: Type: text/html, Size: 1752 bytes --]

Re: proposal: modularize unpack in gnu build system

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <boskovits@gmail.com> skribis:

> 2018-02-11 22:50 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:
>
>>
>> Gábor Boskovits <boskovits@gmail.com> writes:
>>
>> > It seems, that currently we don't have zip in gnu build system, so that
>> > ends up in native-inputs, if we need that to unpack the tarball.
>> >
>> > It would be nice if gnu-build-system would use the appropriate
>> compressor,
>> > and at the same time only depend on the one needed. How could this be
>> > achieved?
>>
>> Why is this necessary?  I don’t see a problem with adding “unzip” to the
>> native-inputs when it is needed to unpack a zip archive.
>>
>> In my opinion this is so easy that I don’t think the slight increase in
>> convenience would be worth the change.
>>
>>
> You might be right about that. What I feel is that:
> 1. this is a recurring newbie question on the irc channel, I've seen it
> already a few times, so support time could be reduced
> 2. this change could make adding new archive types easier in the future.

FWIW I pretty much agree with Ricardo here.  I understand your concerns,
yet it seems to me that this is a minor annoyance (zip archives for
source code are not that frequent anyway), new archive types for source
code don’t show up that often either, and overall I’m wary of
“over-engineering” things like this.

Ludo’.

Re: proposal: modularize unpack in gnu build system

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

2018-02-14 14:49 GMT+01:00 Ludovic Courtès <ludo@gnu.org>:

> Hi Gábor,
>
> Gábor Boskovits <boskovits@gmail.com> skribis:
>
> > 2018-02-11 22:50 GMT+01:00 Ricardo Wurmus <rekado@elephly.net>:
> >
> >>
> >> Gábor Boskovits <boskovits@gmail.com> writes:
> >>
> >> > It seems, that currently we don't have zip in gnu build system, so
> that
> >> > ends up in native-inputs, if we need that to unpack the tarball.
> >> >
> >> > It would be nice if gnu-build-system would use the appropriate
> >> compressor,
> >> > and at the same time only depend on the one needed. How could this be
> >> > achieved?
> >>
> >> Why is this necessary?  I don’t see a problem with adding “unzip” to the
> >> native-inputs when it is needed to unpack a zip archive.
> >>
> >> In my opinion this is so easy that I don’t think the slight increase in
> >> convenience would be worth the change.
> >>
> >>
> > You might be right about that. What I feel is that:
> > 1. this is a recurring newbie question on the irc channel, I've seen it
> > already a few times, so support time could be reduced
> > 2. this change could make adding new archive types easier in the future.
>
> FWIW I pretty much agree with Ricardo here.  I understand your concerns,
> yet it seems to me that this is a minor annoyance (zip archives for
> source code are not that frequent anyway), new archive types for source
> code don’t show up that often either, and overall I’m wary of
> “over-engineering” things like this.
>
>
Ok, fine, I take this proposal back.


> Ludo’.
>

[-- Attachment #2: Type: text/html, Size: 2405 bytes --]