[bug#47027] Disarchive package

["Ludovic Courtès" <ludo@gnu.org>]

Ping!  :-)

Ludovic Courtès <ludo@gnu.org> skribis:

> Hello!
>
> Timothy Sample <samplet@ngyro.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Leo Prikler <leo.prikler@student.tugraz.at> skribis:
>>>
>>>> I've checked and the package seems to build fine with Guile 3.0.2.  I
>>>> think the bytecode mismatch happens, because Guix compiles stuff with
>>>> 3.0.2 by default, but users have 3.0.5 in their system, which is not
>>>> bytecode-compatible.  (As an exception, Guix itself seems to be
>>>> compiled with Guile 3.0.5 for performance reasons).
>>>>
>>>> I think it would be fine to add with Guile 3.0.2, perhaps adding a note
>>>> that Guile 3.0.5 will effectively be required to use Guix interop?  If
>>>> not, could you provide a script, that breaks in a way other than
>>>> recompiling the mismatching code?
>>>
>>> I tend to agree here: I don’t think ‘guile-3.0-latest’ is needed in this
>>> case.  The only case where you need it is if it depends on a library,
>>> such as Guix, that is itself built with ‘guile-3.0-latest’.
>>
>> Well, now I’m second guessing myself.  :)
>>
>> It is just the auto compilation notes and warnings that I’m worried
>> about.  The module closure of “swh.scm” works fine on Guile 3.0.2.
>>
>> Eventually, the daemon will invoke Disarchive via “builtin:download” and
>> “perform-download.scm”.  I intend to use the Scheme interface there,
>> which means Disarchive will be runing on Guile 3.0.5.  For that, it
>> would be preferable to have a Guile 3.0.5 version of Disarchive, right?
>
> No, that’s fine.  Guile 3.0.5 can run 3.0.2 bytecode without any
> warnings; what yields warnings is doing it the other way around.
> Anyway, we can always revisit this if problems come up.
>
>> On the other hand, when using Disarchive to extract metadata (e.g., with
>> Cuirass), the SWH code is not needed at all.
>>
>> I will resurrect my patch for calling Disarchive from Guix, and come
>> back to this when I know exactly what kind of package I need for that to
>> work smoothly.
>
> Yay!
>
>>>> As far as the location is concerned, I personally do not like adding
>>>> too many single-package files.  Would it make sense to add this to
>>>> compression.scm (like gzip) or backup.scm (like libarchive)?
>>>
>>> Maybe there’ll be other packages eventually in archival.scm, like the
>>> SWH Python code?  It’s fine with me, but I don’t have a strong opinion.
>>
>> I don’t feel strongly about it either.  There’s other software besides
>> Disarchive and SWH that could be called “archival”, and I think it’s
>> more accurate than the other options.
>
> Dunno maybe you can do as Leo suggests by putting it in guile-xyz.scm or
> some such.
>
> Thanks!
>
> Ludo’.