On Fri, Mar 25, 2016 at 12:40:12AM -0400, Mathieu Trudel-Lapierre wrote: > On Thu, Mar 24, 2016 at 6:50 PM, Adam Borowski <[email protected]> wrote: > > * Package name : arch-detect > > * URL : https://github.com/kilobyte/arch-detect > > Description : detect architectures supported by your machine/kernel > > > > > It seems like the naming would clash with archdetect (from hw-detect, built > with some libdebian-installer magic). > > That package is currently just a udeb, but it *does* make sense as a > standard package, there might simply be a need to do some renaming.
Thanks for noticing the conflict, I did not look for udebs. > I'm not saying it's a bad name, just that there already exists an > archdetect, and having just a - as a difference may be confusing. It may be > worth combining the two "projects" if possible. I know archdetect should > work on kfreebsd-*. It turns out these two are unrelated: DI's archdetect detects a "subarch" of a given architecture, which answers the question "What kernel would be best for this machine? What doodads like EFI does the machine have?". My arch-detect detects architectures in dpkg's sense that the already running kernel can run (possibly with the help of binfmts/etc). > > This package lets you enumerate architectures that your kernel can run. > > The check is for the ability to run machine code and supporting > > appropriate > > syscall ABI -- you may need to install userland libraries in a chroot, > > container or via multiarch to actually execute non-static binaries of such > > architectures. > > What would the expected output be on a typical amd64 system? Does it > differentiate between EFI and non-EFI? Typical amd64: amd64 i386. With syscall.x32=y also x32. It doesn't deal with hardware drivers like EFI/non-EFI at all. archdetects looks at hardware, my arch-detect at kernel's configuration. On an ARMv7 machine, archdetect might say "armmp" or "omap", arch-detect will list "armel armhf" and, if CONFIG_OABI_COMPAT is set, "arm". Ie, archdetect is useful when installing a new system, arch-detect when you debootstrap a chroot or dpkg --add-architecture. With this in mind, what kind of a name would avoid stepping on DI team's toes? Save for qemu-likes, the main use of my tool is about kernel<->userland ABI. I'd keep the word "arch" somehow, as it's hard to describe it otherwise in a concise way: "kernel ABI" would suggest loadable module compat, userland ABI has many other meanings as well. I have trouble coming up with a new name, could you suggest something? Meow! -- A tit a day keeps the vet away.
