[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#45020] [PATCH 0/2] image: Add system field.
From: |
zimoun |
Subject: |
[bug#45020] [PATCH 0/2] image: Add system field. |
Date: |
Tue, 15 Dec 2020 15:11:33 +0100 |
Hi,
On Sun, 13 Dec 2020 at 15:15, Ludovic Courtès <ludo@gnu.org> wrote:
> It was designed at a time where things were quite different (nowadays
> the “vendor” part is almost always useless), and it’s primarily for
> userland software. It’s well-documented though, no mystery. ;-)
It is not because it is well-documented that I do not feel confused or
it puzzles me or how difficult it is to understand or know about,
especially when the definition appears now a bit awkward. Ah it is the
meaning from the dictionary of mystery. ;-)
Kidding aside, thanks for the explanations. I have bookmarked them.
> --8<---------------cut here---------------start------------->8---
> ;; Description of a platform supported by the GNU system.
> (define-record-type* <platform> platform make-platform
> platform?
> (triplet platform-triplet) ;"x86_64-linux-gnu"
> (system-type platform-system-type) ;"x86_64-linux"
> (linux-architecture platform-linux-architecture) ;"amd64"
> (kernel platform-kernel) ;<package>
> (ld.so platform-ld.so) ;"ld-linux-x86-64.so.2"
> (gcc platform-gcc) ;<package>
> (binutils platform-binutils) ;<package>
> (libc platform-transform-libc)) ;<package>
> --8<---------------cut here---------------end--------------->8---
Naively and what confuse me is the redundancy of the information. For
example, is it possible to do something else than “gnu”? Or when one
thing is fixed, other parameters are also fixed, for instance does it
make sense
"x86_64-linux-gnu"
"i686-hurd"
"arm"
"ld-hurd-arm.so.2"
?
Obviously, the plumbing where it is not a “mystery” for some user is
necessary. But for user like me, the interface should be simple.
> Currently that info is scattered in various pieces in Guix: in base.scm,
> cross-base.scm, linux.scm, bootstrap.scm, etc. Having all that in a
> single place would be an improvement.
Yes.
> Of course this is going beyond what was originally discussed in this
> thread and I’m not claiming this is the solution to work on right now.
> It might be a general direction to follow longer-term, though.
I agree. Aside my usual drift. ;-)
All the best,
simon