Defined more architectures

[n0toose]

• See https://github.com/haiku/haikudepotserver/blob/master/haikudepotserver-packagefile/src/main/java/org/haiku/pkg/model/PkgArchitecture.java

---

I tried to check the web application to see a list of applications that run on non-x86/x86_64 architectures and saw that these architectures were not listed, so I tried implementing that myself. From my understanding, architectures are initialized with a code and are then listed on the website thanks to a function that obtains all of the architectures that were initialized in haikudepotserver-core. I called the commit "Defined more architectures" for now because I am frankly not sure whether I achieved what I wanted to achieve.

From my understanding, which is likely to be inaccurate, haikudepotserver-core-test is a slightly torn down version of haikudepotserver-core with some example metadata for testing purposes. I noticed that there was some code that was implemented for voting for packages, which included references to the x86_64 architecture. I wasn't sure whether I forgot to implement something, or whether that's negligible. I also was not sure what this was supposed to be or whether I should have touched it at all.

[andponlin]

Hi there @panos -- hey thanks for the PR.

It's not quite right because instead of adding these Java-source constants, the new values need to be added into a database table using SQL statements. This can be achieved by adding a new flyway migration file under haikudepotserver-core/src/main/resources/db/haikudepot. To work, the codes must match the platform level architecture code used in the HPKR files so those codes you have used may not be correct.

I'm not however feeling that it makes sense to show all these architectures in the web interface until it the operating system works reliably on the architecture? Otherwise it is likely to clutter the user interface and could confuse people.

[n0toose]

It's not quite right because instead of adding these Java-source constants, the new values need to be added into a database table using SQL statements. This can be achieved by adding a new flyway migration file under haikudepotserver-core/src/main/resources/db/haikudepot

Makes sense. So, gotta add more tables and be done with it, the Java constants are correct but not enough.

To work, the codes must match the platform level architecture code used in the HPKR

.hpkg, just to be completely sure?

I'm not however feeling that it makes sense to show all these architectures in the web interface until it the operating system works reliably on the architecture? Otherwise it is likely to clutter the user interface and could confuse people.

Well, this only really affects drop-down menus and it will clutter it either way at some point or another, won't it? I tried to access the site in order to establish the progress as far as certain ports are concerned, which packages were marked as untested and which packages were officially released. It was a bit frustrating when I had to work with grep instead, when there's an available interface literally meant for aggregating this sort of information. Maybe we could just do this for ports of Haiku in different architectures that actually get past the initial booting process?

Moreover, am I supposed to do anything regarding the ratings that the user is allowed to make to packages?

(Huge apologies for the "non-consensual internship", I'm just trying to amend something that personally bothered me in the user interface and simultaneously understand how Haiku's backend systems function so that I can be more useful in the long run.)

[andponlin]

Makes sense. So, gotta add more tables and be done with it, the Java constants are correct but not enough.

No more tables required; just more rows inserted in the haikudepot.architecture table (see here).

.hpkg, just to be completely sure?

The HPKG is the file format for the package and HPKR is the file format for the description of the packages in a repository. You can find out more about this at /docs/develop/packages/FileFormat.rst in the Haiku source. The two formats are somewhat similar.

Sorry; what I said earlier is not quite right. Look for B_HPKG_ATTRIBUTE_ID_PACKAGE_ARCHITECTURE in that document and you will find a list that is probably out of date. These numerical values correlate to the Java class PkgArchitecture in the HDS source. The lower-case values of these enums is the correct code to use in the database rows' code. For example;

INSERT INTO haikudepot.architecture (id, code) VALUES (nextval('architecture_seq'), 'riscv64');

Well, this only really affects drop-down menus and it will clutter it either way at some point or another, won't it?

At the moment, as far as I am aware, a fully working platform is not possible with ARM, SPARC or RISC-V so is there any sense in displaying to end users options that to all intents and purposes don't work? It seems exposing these not-yet-working architectures in the UI at this point in time would serve as a source of confusion.

If you were interested, you should be able to download the HPKR for the repository and dump the list of packages out of that file. You can use the tool PkgDumpTool which is available in the HDS source if you wanted to try it.

[n0toose]

TL;DR Get rid of the Java constants and just add the rows, got it.

(Also I literally forgot about the existence of HPKR's, thanks!)

[andponlin]

@n0toose ; are you going to take this any further? I actually think this would be more useful after the Risc-V and ARM-64 ports are viable for day-to-day use. If you are happy to leave this for now I will close this issue.

[n0toose]

It's been close to a year and I've left this issue to rest as I've gone through a lot of changes in the meantime. Unfortunately, as I am still largely unavailable and unaware as to how I could possibly reproduce this instead of changing lines of code blindly, I think this would be better off in someone else's hands.