Some way to mark "native" applications

[waddlesplash]

This should be some sort of tag/flag in addition to whatever category an application is in that we can set within HDS and then filter by in HaikuDepot.

As discussed on the forums.

[andponlin]

Hello; that's a good idea. Would it be best to have an "underlying framework" selection from a list of possibilities;

• Haiku Native
• QT
• Java
• Console
• WxWidgets
• Other Compatibility Layer

Are you able to also link to the forum conversation so I can see what was discussed.

[waddlesplash]

https://discuss.haiku-os.org/t/list-of-haiku-applications/7400/5

Most of these we can probably classify automatically. I.e., look for an app: provide in the package, and then check for a requirement on any library from the qt5 package, the wx package, etc.

[kallisti5]

easy idea, lets just look for a predefined set of key dependencies.

Depends on: (42 other packages)
Depends on: (qt5) (41 other packages)
Depends on: (wx) (3 other packages)

The idea is we "whitelist" dependencies we want to call out.. and then have a bubble for "other" dependencies

[kallisti5]

[andponlin]

Hello Alex; Something like this should be quite possible. To make this change, I need to store information into the database. This requires a database schema change which is no problem because HDS uses a schema-migration system. However one of the following needs to happen to make a safe deployment where the deployment contains schema migration;

1. You provide me with a dump of the production database to test the migration on
2. You test the deployment on a pre-production system first

Could we discuss on the mailing list or off-list emails how we can achieve this.

[andponlin]

Taking a wee look at how these detections might work.

I have a nice command-line tool in the HDS source which reads a hpkr file and dumps all the attributes / dependencies / provides etc... so has been quite helpful here.

WX

I can see the package wxqt and so I guess that would end up being the "requires" to detect?

QT

Here is an example application that appears to be dependent on QT;

package : STRING : goldendict
  package:name : STRING : goldendict
  package:summary : STRING : Dictionary lookup program
...
* libqt5core
    package:resolvable.operator : INT : 4
    package:version.major : STRING : 5
      package:version.minor : STRING : 13
      package:version.micro : STRING : 0
* libqt5gui
    package:resolvable.operator : INT : 4
    package:version.major : STRING : 5
      package:version.minor : STRING : 13
      package:version.micro : STRING : 0
* libqt5help
    package:resolvable.operator : INT : 4
...

Here is a list of all those "QT looking" dependencies;

• libqt5core
• libqt5gui
• libqt5network
• libqt5widgets
• libqt5core
• libqt5core
• libqt5gui
• libqt5network
• libqt5script
• libqt5widgets
• libqt5xml
• libqt5core
• libqt5dbus
• libqt5gui
• libqt5widgets
• libqt5core
• libqt5gui
• libqt5widgets
• libqt5concurrent
• libqt5core
• libqt5dbus
• libqt5gui
• libqt5printsupport
• libqt5sql
• libqt5svg
• libqt5widgets
• libqt5core
• libqt5gui
• libqt5network
• libqt5sql
• libqt5widgets
• libqt5core
• libqt5dbus
• libqt5gui
• libqt5network
• libqt5opengl
• libqt5widgets
• libqt5core
• libqt5gui
• libqt5network
• libqt5webkit
• libqt5webkitwidgets
• libqt5widgets
• libqt5core
• libqt5gui
• libqt5printsupport
• libqt5svg
• libqt5widgets

I think that a requires package pattern like ^libqt\d+.*$ would make sense here to detect a dependency on QT and hence make this package labelled as a QT

Java

I can see that there are some JDK looking requires;

• openjdk8
• openjdk11
• openjdk12_jre
• openjdk8_jre
• openjdk11_jre
• openjdk11
• openjdk12
• openjdk12
• openjdk8

So perhaps if a package requires a package matching the regex ^openjdk\d+(_jre)?$ would work?

Haiku Native

Is there a clear way to distinguish this?

Console

Maybe I could check to see if libncurses is a dependency, but that's a bit weak since many console application's won't use ncurses. Any way to detect this?

Others?

Any others?

[irtusb]

i think a tag would be the best solution here. First time should be an automated tool that marks the wx, qt and possibly other. Maybe not java as it can be used as an extension point and not in the main interface.

After the check is done recipes should be fixed to include the apropiate tag. Nomenclature: gui/native, gui-wx, gui::java ?

edit: Responsibility should go on the package maintainer, no one else

[andponlin]

See this Haiku-side ticket.

[andponlin]

Ah of course it has to implement a full "solver" (quite a big job) to resolve dependencies transitively.

[waddlesplash]

We already have a full solver, another should not be implemented. Why not just hook into or invoke pkgman/"package"/"package_repo" to do the solving?

[andponlin]

Hmmm... taking that path has also got challenges to deal with. Well I will think about the best way forward.

[andponlin]

Discussed on the mailing list; maybe the best path forward would be to just keep a flag for native applications which is handled manually as there are so many edge cases that would need to be dealt with, Coming up with a definition for what a "native" application is would be helpful (@humdingerb).