On 01/01/16 19:28, Pjotr Prins wrote:
On Fri, Jan 01, 2016 at 06:27:21PM +1000, Ben Woodcroft wrote:
It seems there's 30 packages to be updated, out of the 107 in
ruby.scm. Going through each of these individually seems a little
tedious, can we do them in bulk somehow or do they have to be
committed individually? Building and testing all packages that
require these packages would be a start - is there any way to list
all dependent packages?
gnu/packages/ruby.scm:2807:13: ruby-cutest would be upgraded from
1.2.2 to 1.2.3
gnu/packages/ruby.scm:333:13: ruby-rspec-mocks would be upgraded
from 3.2.1 to 3.4.0
(etc)
I don't think it is a good idea to automatically update
packages. Reason being that packages should be updated by someone who
is actively using that new version. Automated tests are one thing,
real user feedback another. Not to mention that many gems don't have
tests ;).
I think we should update the package definitions so that more have
tests, and failing that import the library so we know it can at least be
loaded, like this:
+ `(#:phases
+ (modify-phases %standard-phases
+ (replace 'check
+ (lambda _
+ (zero? (system* "ruby" "-Ilib" "-r" "ansi")))))))
I would prefer to do this testing in an environment where only the propagated
inputs are loaded, but I'm not sure how to do this. But I digress.
Do you think it would be a good idea to provide a "bleeding edge" repository so
that users can more easily help with testing? Perhaps also a branch that only updates
according to semantic versioning?
What is useful is to generate (export) an updated package using the
old one as an input. Or show a diff of version + SHA. That way it
becomes reasonably easy to update packages.
I'm not sure what you mean. guix refresh has the --update flag, which
updates the version and source SHA hash in the source code - useful.
Thanks,
ben
