Re: Copying whole /gnu/store from USB does not work

[David Thompson <dthompson2@worcester.edu>]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> Now we need to add Ruby gems and GNU Guix will be the default
> deployment system for many.

Help wanted. ;)

Two major problems to deal with:

1) Propagated inputs: Dynamic languages typically don't have an
equivalent to RUNPATH for ELF binaries.  Thus, for Python (and others),
we have to propagate all of the python libraries along with each package
so that they can all be found in a particular load path.  This in
unideal.  I haven't found a way to hardcode the location of libraries as
part of the build process.  If it can't be reasonably solved, we'll just
propagate the inputs like every other dynamic language.

Do you know a way that we could avoid this for Ruby gems?

2) Circular dependencies: Rspec is a particularly important Ruby gem to
package.  Pretty much every Ruby project uses it for their test suite.
However, a lot of Rspec's dependencies use Rspec!  The only thing I've
come up with is to produce a set of private packages for all of Rspec's
dependencies whose build processes skip the test suite.  Then, with
Rspec packaged, create public versions of the packages with Rspec as a
native input and the test suite enabled.  The dependency tree isn't
exactly shallow, though.

The Rspec maintainer failed to understand this issue, because the system
in place at rubygems.org doesn't run test suites or build the gems at
all.  People just upload the final product and no one notices that
there's nasty circular dependencies.

Thoughts?

Nice to see you poking around with Guix again, Pjotr.

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate