GNU bug report logs -
#74078
[PATCH] gnu: Add dart
Previous Next
Reported by: Jørgen Kvalsvik <j <at> lambda.is>
Date: Tue, 29 Oct 2024 03:56:02 UTC
Severity: normal
Tags: patch
Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
Message #16 received at 74078-done <at> debbugs.gnu.org (full text, mbox):
On 11/5/24 06:20, Maxim Cournoyer wrote:
> Hi Jørgen,
>
> Jørgen Kvalsvik <j <at> lambda.is> writes:
>
>> * gnu/packages/dart.scm: New file.
>> * gnu/local.mk: Register it.
>>
>> Change-Id: Idbdcf4e30790b3225bf86a36a0a4c4b081b557aa
>> ---
>> gnu/local.mk | 1 +
>> gnu/packages/dart.scm | 101 ++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 102 insertions(+)
>> create mode 100644 gnu/packages/dart.scm
>>
>> ---
>>
>> Hello,
>>
>> This is a port of the nixpkgs Dart compiler package [1]. I am interested
>> in it specifically because it is a transitive dependency of Hugo [2],
>> and I figured I other people might be interested in these packages, too.
>>
>> The from-source build of Dart is quite the pain (nixpkgs seems to have
>> given up, but I do not know the story there). I looked around and while
>> I did not find a strict rule saying "source only", it does stand out by
>> relying on prebuilt artifacts. For my current needs it is good enough,
>> and I hope that in the future it could get a proper source build. I saw
>> there was an effort a few years ago, but it appears to have stopped
>> completely.
>
> What kind of prebuilt artifacts are we talking about?
>
> [...]
>
>> +(define-public dart-3.5
>> + (package
>> + (name "dart")
>> + (version "3.5.4")
>> + (source (origin
>> + (method url-fetch)
>> + (uri (string-append
>> + "https://storage.googleapis.com/dart-archive/channels/stable/release/"
>> + version "/sdk/dartsdk-"
>> + (match (%current-system)
>> + ("x86_64-linux" "linux-x64")
>> + ("i686-linux" "linux-ia32")
>> + ("aarch64-linux" "linux-arm64")
>> + (_ "unsupported"))
>> + "-release.zip"))
>> + (sha256
>> + (base32 (match (%current-system)
>> + ("x86_64-linux" "0rv9rp8g5blhncqwciymhxh3z2832yp54lphxgsvkmm9y8s5w34d")
>> + ("i686-linux" "02kv119swcp7y4n3yb2i5a4dagjpf0zq3b3an1apahj5zn6ak41g")
>> + ("aarch64-linux" "1v437zpksk0jhib6vhpcbvv715mv32zmwby8b3p9qd3k67fn87d9")
>> + (_ "0000000000000000000000000000000000000000000000000000"))))))
>
> Given the "sources" are architecture-specific...
>
>> + (build-system copy-build-system)
>
> ... and that we aren't building them, I suppose we are talking about
> binary executables.
Correct.
> [...]
>
> While we do have some other packages that do not bootstrap entirely such
> as Vala, the situation is not comparable with simply fetching its
> binaries and copying them to the store.
>
> I don't think this can be added to GNU Guix as it is, as our policies
> are strict about being able to build from source (see the pain we go
> through to build recent rust for example -- a long bootstrap chain
> rooted in mrustc).
>
> I'd suggest creating a merge request against a different channel that do
> not have such high standards/requirements such as NonGuix [0].
>
> I'm now closing this ticket. Thank you for producing it, and apologies
> for the outcome, but I think it's important to stick to this important
> property of Guix called 'referential transparency', which wouldn't be
> quite the same if the references were opaque binaries :-).
No problem - frankly, I expected as much (and appreciate it), but wanted
to check to be sure. As Sharlatan pointed out there is an older, maybe
stale, bootstrapping effort, which could be revived.
As for Hugo (which is what I cared about) it has a bunch of other
dependencies that aren't in guix and that don't really mesh too well
since the go build system doesn't do modules yet, and some dependencies
are .zip/modules-only.
>
> [0] https://gitlab.com/nonguix/nonguix/
>
This bug report was last modified 190 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.