ludo@gnu.org (Ludovic Courtès) writes: > What I meant is that, in the functional model as implemented in > Nix/Guix, the derivation graph captures all user-land software that > comes into play. But it does not capture the hardware and kernel, both > of which are taken from granted. > > Thus, this system string allows us to represent the dependency on a > kernel and hardware architecture. In turn, this allows us to > distinguish between, say, the Guile derivation for x86_64 and that for > MIPS. > > ... > > The ABI and file format are entirely (or almost entirely) the > responsibility of user-land software (how you configure the toolchain > determines what ABI you use, for instance.) Thus they’re necessarily > captured by the dependency graph; no need to store that information > elsewhere. > > ... > > It’s the toolchain that shows up in the graph that determines what ABI > is targeted. I think I understand now. I was missing the fact that what ABI you use is determined by how you configure the toolchain. I don't (yet!) know as much about compilation, cross-compilation, and the GNU toolchain as I'd like, so I appreciate you taking the time to explain to me what must have seemed obvious to you. >> What is the recommended way to package software in Guix when the >> software's behavior or the output of the derivation that builds it can >> be influenced by the value of the "vendor" part? > > There are two or three examples of that, which are U-Boot, GRUB, and > Linux-libre. We essentially define several package variants for each of > these, depending on the target hardware. OK, that makes sense. >> For example, suppose I purchase an x86_64-linux server from a vendor >> called FooCorp > > Nothing to worry about in this case. :-) Do you say that because if it mattered, we could just define a separate package that takes advantage of the vendor-specific feature, like we might do for U-Boot and GRUB? >> Yes, I understand. The GNU triplet concept makes more sense to me now. >> However, if information like the vendor and the OS/ABI are important >> enough to put into the GNU triplet, I still don't understand why we can >> get away with omitting those details from the Guix system string. > > I hope I answered that question! Yes, I think you did. I really appreciate it! > That said, you may get better-informed answers on the GCC or Binutils > mailing lists. :-) Thank you for the suggestion. I'll keep it in mind. It's good to know where to go for help! -- Chris