From: Maxime Devos <maximedevos@telenet.be>
To: 57491@debbugs.gnu.org, Daniel Sockwell <daniel@codesections.com>
Subject: [bug#57491] [PATCH] patch series: Update Raku ecosystem
Date: Wed, 7 Sep 2022 23:56:47 +0200 [thread overview]
Message-ID: <e01718cc-4ff3-d82f-c450-1948a529b8aa@telenet.be> (raw)
In-Reply-To: <b7d3322144715c3f38fe1f99d543ec64@codesections.com>
[-- Attachment #1.1.1.1: Type: text/plain, Size: 4261 bytes --]
> -@item Great Unicode support, with strings represented at grapheme level
> +@item Unusually strong Unicode support enabled by strings represented at
> +grapheme level and an embedded copy of the Unicode Character Database
IIUC, this means that previously, it didn't include a copy, and now it
does? If so, that's bundling, which is to be avoided in Guix such that
there is only a single copy to keep up-to-date. From (guix)Submitting
Patches:
> 8. Make sure the package does not use bundled copies of software
> already available as separate packages.
>
> Sometimes, packages include copies of the source code of their
> dependencies as a convenience for users. However, as a
> distribution, we want to make sure that such packages end up using
> the copy we already have in the distribution, if there is one.
> This improves resource usage (the dependency is built and stored
> only once), and allows the distribution to make transverse changes
> such as applying security updates for a given software package in a
> single place and have them affect the whole system—something that
> bundled copies prevent.
(If this was already the case in the previous version, that's still bad,
but then it can be left for later, being independent of this patch.)
I noticed you removed the mention of the garbage collector, is this
intentional? Seems a useful feature to me ...
On nqp-configure: Are you sure that 'bin' should be installed in
'.../bin'? Looking at the Git repository, make.nqp does not have a
shebang and can hence not be directly run, maybe you should add a shebang?
Also, is there appear to be some tests in 't', why aren't they run?
There is a 'rakudo-build-system', maybe this rakudo-build-system can
properly build this package (including tests, maybe it even adds a
shebang for the make.nqp)?
On nqp: why the switch from downloading the source code from the
apparent official site "rakudo.perl6.org" to GitHub?
> + (substitute* "t/09-moar/01-profilers.t"
> + (("ok.*\\$htmlpath" html-test-text)
> + (string-append "todo \"harness5 fails to write html profile\";"
> + html-test-text)))))
What's the issue here? Is it a limitation of the Guix packaging, or
could it perhaps be an upstream bug? If the latter, upstream needs to be
informed such that they can fix the bug.
On the new package description: everything in Guix is free software, the
"open source" is superfluous. The information on who designed it is
interesting from a historical perspective, but I don't think it is
useful information for package descriptions. It's getting close to
marketing phrases (see (guix)Synopses and Descriptions) with
"prioritizes expressiveness", "optimised for fun" and "superpowers",
"linguistically inspired" (I mean, doesn't every new language try to
gain those properties, and how would you objectively-ish verify those
compared to other languages (ignoring C and assembly and such), and what
does "linguistically inspired" even mean?). The other things can stay I
suppose.
I've noticed the environment variable changed (PERL6LIB -> RAKULIB), but
(guix build rakudo-build-system) hasn't changed PERL6LIB to RAKULIB.
Can you verify that our various perl6-... libraries still build, and
that when doing, say, "guix shell rakudo perl6-json-name --
whatever-rakudos-binary-name-is", you can still use perl6-json-name in
whatever is rakudo's name for a REPL?
You add some patches, but they need to be registered in gnu/local.mk as
well, please do so.
On the patch file name: it looks a little suspect, perhaps if you run
the linter on the packages it will have a comment about the file names.
On commit messages: they don't follow our conventions. Running "git
log" will result in plenty of examples, also see
<https://www.gnu.org/prep/standards/html_node/Change-Logs.html>. (They
tend to be a bit terse, but you can always add additional information to
them even when not strictly required.)
A new copyright line can also be added.
Greetings,
Maxime.
[-- Attachment #1.1.1.2: Type: text/html, Size: 5684 bytes --]
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next prev parent reply other threads:[~2022-09-07 21:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-30 16:31 [bug#57491] [PATCH] patch series: Update Raku ecosystem Daniel Sockwell via Guix-patches via
2022-08-30 16:45 ` Daniel Sockwell via Guix-patches via
2022-08-30 16:49 ` Daniel Sockwell via Guix-patches via
2022-08-30 16:59 ` Daniel Sockwell via Guix-patches via
2022-09-07 16:26 ` Daniel Sockwell via Guix-patches via
2022-09-07 21:56 ` Maxime Devos [this message]
2022-09-08 2:18 ` Daniel Sockwell via Guix-patches via
2022-09-08 9:15 ` Maxime Devos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e01718cc-4ff3-d82f-c450-1948a529b8aa@telenet.be \
--to=maximedevos@telenet.be \
--cc=57491@debbugs.gnu.org \
--cc=daniel@codesections.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.