GNU bug report logs -
#53865
[PATCH] gnu: ruby-parser: Update to 3.1.0.0.
Previous Next
Reported by: jgart <jgart <at> dismail.de>
Date: Tue, 8 Feb 2022 02:12:01 UTC
Severity: normal
Tags: patch
Done: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Bug is archived. No further changes may be made.
Full log
Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):
On Wed, 09 Feb 2022 16:05:30 -0500 jgart <jgart <at> dismail.de> wrote:
> On Wed, 09 Feb 2022 21:00:36 +0100 Nicolas Goaziou <mail <at> nicolasgoaziou.fr> wrote:
> > jgart via Guix-patches via <guix-patches <at> gnu.org> writes:
> >
> > > On Wed, 09 Feb 2022 16:05:52 +0100 Nicolas Goaziou <mail <at> nicolasgoaziou.fr> wrote:
> > >> Hello,
> > >>
> > >> jgart via Guix-patches via <guix-patches <at> gnu.org> writes:
> > >>
> > >> > * gnu/packages/ruby.scm (ruby-parser): Update to 3.1.0.0.
> > >>
> > >> Applied on core-updates (it entails building 5k packages).
> > >
> > > Thanks Nicolas!
> > >
> > > What is your workflow for determining whether it goes to core-updates?
> >
> > I did
> >
> > guix refresh --list-dependent ruby
> >
> > It reported 5000+ packages. According to Submitting Patches section of
> > the manual, above 1800, it should go to core-updates (at the moment).
What do you think if we were to add a smart user message to the `guix refresh
--list-dependent ...` command?
I was thinking something along these lines:
```
$ guix refresh --list-dependent ruby-parser
Building the following 1991 packages would ensure 5378 dependent packages are rebuilt: ...
ruby-parser reported 5000+ packages. According to Submitting Patches section of
the manual, above 1800, it should go to core-updates (at the moment).
```
Like that, the command reminds the user/calculates for the user what
branch to put the package in.
I'm imagining it would be as easy as just getting the length of the output and
matching against it the appropriate message?
This bug report was last modified 3 years and 101 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.