Re: repositories.conf (and64 and x86_64)

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%mnx.io@localhost> writes:

(fully agreed on configure exactly one)

>>b) x86_64 vs amd64
>
> I think one is a symlink to the other.  pkgin will expand $arch in
> repositories.conf so in theory the x86_64 is more correct as it is
> MACHINE_ARCH, but it really doesn't matter.

Yes, symlinks.

There are two separate concepts for hardware types: the CPU and then the
larger machine constructucted of a CPU and other things.  POSIX only
recognizes "hardware type":

  https://pubs.opengroup.org/onlinepubs/9699919799/

But NetBSD and other BSDs separate:

  uname -m: "machine hardware name"
  uname -p: "machine processor architecture name"

but the labels are just labels and sometimes are a bit odd.

The canonical NetBSD example is -p being "x86_64" to refer to a CPU that
implements AMD's 64-bit version of the 386, and -m being "amd64" to
refer to a computer which is a PC architecture built around that CPU,
but having specific kinds of IRQs, timers, buses.

Another NetBSD example is -p being earmv7hf-el, a 32-bit ARM conforming
at v7 of the arch spec, with a floating point unit, and running in
little endian mode.  And then -m being evbarm, being one of a number of
common boards that contain this chip.  (In this example, a RPI 2 or 3
running as 32-bit.)

On the NetBSD FTP server, the actual packages are in directories by
"uname -p".  There are symlinks from "uname -m" values.  The point is
that by the time you are running the OS, the user-space ABI is the same.

NetBSD sometimes has multiple "uname -m" names for the same "uname -p",
typically when there are distinct families built from the same chip.
macppc and evbppc are one example.  The poster child for this is m68k,
which has the following symlinks:

  amiga atari cesfic hp300 luna68k m68k mac68k mvme68k news68k next68k
  sun3 x68k

Linux however does not do this; on a machine NetBSD would call amd64,
uname -m is "x86_64" and uname -p is "unknown".  On RPI3, -m is "armv7l"
(which is silent on FP, but perhaps v7 requires FP?) and -p is
"unknown".  I don't understand this.

>>http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.3/All
>>http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.2/All
>>http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.1/All
>>http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_2023Q1/All
>
> Unfortunately the NetBSD project does not expose the branch in all
> cases, which may be contributing to this confusion, as it's not clear
> to the user what branch e.g. the top 3 URLs here are using, and
> whether the 9.0_2023Q1 repository is actually newer.

The values 9.1, 9.2, 9.3 are just symlinks to 9.0.  It is policy that we
do not make ABI changes on stable branches, and that is the case for 9.

Further, 9.0 is a symlink to a particular set, in theory advanced to the
next quarter as soon as it is ok.

The point of the symlink scheme is that people can put their release in
the version slot and their uname -m in the arch slot, and get the right
bits.

However in practice this process is troubled, for complicated reasons I
won't address here.  However the per-branch directories are present (as
they are built, which can take a very long time for slow systems like
vax!).

So, if you are using a normal PC that is amd64/x86_64, and using some
variant of NetBSD 9 (in which case the further along the netbsd-9 branch
you are the better), then I would suggest today:

  https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_2023Q1/All

Some time in July, there will be bits in 9.0_2023Q2, but we haven't
started the freeze, much less finished it and built packages.  It's
totally fair to ask on pkgsrc-users@ if the binary sets are ok 7 days
after the branch is cut.