guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#47027] Disarchive package


From: Leo Prikler
Subject: [bug#47027] Disarchive package
Date: Sun, 21 Mar 2021 12:10:57 +0100
User-agent: Evolution 3.34.2

Am Sonntag, den 21.03.2021, 11:29 +0100 schrieb Ludovic Courtès:
> Ping!  :-)
I've pushed guile-quickcheck as
4cd88522f233dcb9affa3d3b0eada154439487c1, so we now only need to
discuss what to do with (guile-)?disarchive.

> > 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’.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]