Remove concept of subarchitecture

[nephele]

I would like to get rid of the concept of a subarchitecture. To achieve this i would propose to re-organize the layout of some system relevant directories, to be split up into arch/ABI seperated dirs. This should allow in the future to also install aarch64 packages directly on amd64 without any patching, and have filetypes execute those via Qemu.

current layout:

/system/
├── add-ons
├── apps
├── bin
├── boot
├── cache
├── data
├── demos
├── develop
├── documentation
├── lib
├── non-packaged
├── package-links
├── packages
├── preferences
├── servers
├── settings
└── var

proposed layout:

/system/
├── add-ons
├── apps_shared
├── apps_x86_64
├── bin_shared
├── bin_x86_64
├── boot
├── cache
├── data
├── demos
├── develop_shared
├── develop_x86_64
├── documentation
├── lib_shared
├── lib_x86_64
├── non-packaged
├── package-links
├── packages
├── preferences
├── servers
├── settings
└── var

In this proposed layout the _shared represents architecture unspecific files, and _x86_64 is the native architecture of the machine.

Thoughts?

[miqlas]

Reading the totle of the ticket i tought you propose the removal of the gcc2 toolchain alltogether from x86 builds, while keeping the runtime libs around.

The proposed folder structure seems to be a mess to me which would result in much confusion, newcomers installing libreoffice-arm mistakenly then complaining everything slow, etc. Or maybe not.

[waddlesplash]

Installing libraries for some other architecture would probably be a deeply buried option, I don't think that's a big concern.

I think ultimately this proposal may require some rethinking of how dependencies are managed. Right now we use an "arch suffix", but this way, everything would require that arch suffix, so maybe we should drop the "suffix" and consider all provides as arch-relevant.

I also think that we can probably just intermingle the apps directory (?), and then just have develop/<arch>/, lib/<arch>/, etc.

[nephele]

My thinking on develop_arch over develop/<arch> is that tools that install in the wrong place get a not found error, or create that dir itself, instead of putting stuff into develop/ where it no longer belongs directly.

for apps, it might be neat to be able to test e.g a 32bit version against a 64bit version, which would require coinstallation, how would you solve this with a shared apps/ directory?

[tqh]

I think the proposed layout is overcomplicated. Why would we want to add a lot of technical terms in directories for users? I'd rather prefer to thinking to reduce number of directories, I even think non-packaged is something that should be handled better somehow.

[waddlesplash]

Tools should simply not install into develop/ directly under a model like this, and HaikuPorter can catch such errors when they occur (and warn if they are placed in the wrong directory in the first place.)

[pulkomandy]

I don't understand what "shared" is in your layout. Is it for the "any" architecture, things like python or bash scripts?

I think the current approach with subdirectories (bin/x86, etc) is fine. I don't see how the _ really helps. bin/ would not be in the PATH, so if you put a binary there, you would quickly notice that there is a problem.

It's still unclear what the plan going forward is. I think secondary architectures will be used a lot less when we remove gcc2. We decided to keep gcc2 as the main architecture for the 32bit version of Haiku for simplicity: we now have the 32bit version for all legacy needs (old hardware, people needing BeOS apps) and the 64bit version for everyone else.

For R2 I'd say we would go 64bit only, with new API as the "main" architecture and an R1 compatible one as a secondary architecture.

While we may need cpu emulation in some cases, it is going to be limited for now, because most of the packages are opensource and can be rebuilt natively for any cpu as needed. So it's really a "main" arch with most things and rarely a "secondary" arch for legacy or other specific reasons.

Thinking about it this way, I think the current layout is fine. In the current situation (with gcc2 being the main arch) it does not work so nicely, but that's something that is eventually going away.

[X512]

I think secondary architectures will be used a lot less when we remove gcc2

32 bit can be used as secondary architecture for 64 bit. Executables for different CPU running by emulation can be used. Also I think that gcc2 should be never completely removed, it can become optional in R2. It is nice to have absolute backward compatibility like Windows, it even still support 16 bit executables by optional VTVDM package. 3-rd party VDM is available for 64 bit Windows: ​https://github.com/otya128/winevdm.

[nephele]

I am not sure how the layout is on x86 currently, if it is lib/x86/ that is fine, just aslong as the main abi/arch is next to it as a seperate folder.

One subgoal here is to have one builder for each arch, and not introduce any sub-arch for gcc2 on amd64 or x86 on amd64, but simply allow the x86 or gcc2 packages with a neat path to be coinstalled next to the native architecture, whether or not that would use qemu or so.

On an additional note, i don't really agree with dropping beos compat, it should be still feasible to do, my plan would be rather to expand this to run on other architectures via qemu aswell.

If we want to do abi versioning maybe that should be reflected now aswell so it does not become a problem in the future?

[nephele]

Pulkomandy mentioned on irc the posibility of mounting foreign arch packages to a diferent tree, like /boot/system_x86/. this seems like a beter solution to me.

The question would be then if the x86 stuff on x86_gcc2 should be moved there

[waddlesplash]

I still think per-arch subdirectories like we have now are the best; this is also what Linux and the BSDs do, so there is precedent for it, also. The only question is whether the primary arch should also be placed in a subdirectory, and I am inclined to agree that it should be.

[X512]

I suggest automatic remapping of executables from $image to $(getarch)/$image by package_fs and eliminating secondary architecture packages. package_fs will automatically convert package to secondary at runtime is needed.

[nephele]

Sounds a bit like mounting to system_$arch instead of system for non-matching arches