HaikuDepot - Add system requirement to HPKG packages

[lelldorin]

I would like, if one in a hpkg package also the possibility would have a system requirement to define.

So the user can see in HaikuDepot which minimum system requirements (processor, Haiku version, screen resolution ...) are required for the program or game

[humdinger]

This information is needed or available only for extremely few applications. It can very well be provided in the DESCRIPTION of the package.

[richienyhus]

Looking at how it is done on other systems: Both the Windows store and Google Play include information on what architectures are supported by the app and what major OS release is required to run (for example: "Android 4.1 & up" or "Windows 8, 8.1 & 10").

However they never go into greater detail than that, as such extra information is put into the application's description. Further the app version of Google Play (but not the web version) doesn't display this information and simply hides apps that are not supported by the system.

[humdinger]

HPKGs already have a REQUIRED field for the needed Haiku version. I'll close the ticket then. Reopen, if I missed or misinterpreted something.

[lelldorin]

I can understand that you do not want to install something like this because the others do not have (typical thinking). But just because it does not make the others it does not have to be wrong? Also, I find this suggestion is rejected too quickly.

Even if only a few programs would require this, it does not mean it will not change in the future. Especially when it comes to the screen resolution, this information would be very interesting for people with small notebooks. You must bear in mind that the programs available there do not have any packaging and therefore the system requirements are not available. Even if it does not appear at the moment that there will be sometime comprehensive games and programs for Haiku, one should nevertheless consider a development in this regard.

[humdinger]

I have reopened the ticket, but I would still like to hear arguments why it's not enough to put the information on special requirements into the package description. What is to be gained by an additional field "system_requirements" which will, I assume, be a non-structured text field that'll be filled with arbitrary terms like "800x600, 2 cores > 2ghz, 1gb RAM...etc."? If users look for an app, they'll see any requirements the author of the package deems important in the decription.

You must bear in mind that the programs available there do not have any packaging and therefore the system requirements are not available.

I don't understand this: all HPKG are packages and do include their system requirement (haiku version, dependencies).

[lelldorin]

This is often the point that many authors overlook or forget. So it would be important to have a defined range here, which indicates the dependencies. This is how everyone sees this field and hopefully makes more thoughts about this topic.

Can not you also have the dependencies for the hpkg listed in the preview list? This is always experienced only when you press "Install".

[lelldorin]

You must bear in mind that the programs available there do not have any packaging and therefore the system requirements are not available.

I don't understand this: all HPKG are packages and do include their system requirement (haiku version, dependencies).

I mean the packaging of purchased software where I can see if the game / program can run at all on my system (as an example),

[pulkomandy]

If it is a free-form string, we should just add it to the description (which is shown in HaikuDepot, before you download the package).

If we want something more structured, we could do something similar to Android and the Google Play store. There, the apps describe what they need in a formalized way (needs a webcam, needs a high resolution display, etc), and the play store filters out apps that are not compatible with the device.

This is pretty much required for Android because there is a large diversity of hardware (tablets, phones, ...) and very specific-focus for each app. I think the situation in Haiku is a bit different at the moment. No one has 3D acceleration, very few people have a webcam, it is hard for the OS to know if your sound input works or not.

And on the other hand, applications tend to cover wider use cases. For example, Sequitur would normally be used with MIDI input, but can also be used to view MIDI files or even edit them with a standard mouse and keyboard.

There is also the issue that hardware may come and go. PhotoGrabber needs an USB attached picture camera to work, but it may not be plugged at the moment you look at the app in HaikuDepot.

As a result, automatically filtering the applications based on requirements will be difficult, and maybe counter productive because of too many false negatives (apps don't show, but they would work fine). And if we can't do that, then what's the point of a specific field? Why not just let developers include this in the package description in the rare cases where there are specific needs?

[michel]

IMHO, if your app requires a specific piece of hardware like a webcam, then it's the programmer's job to detect this in a post-install script or applet and display an alert: "You don't seem to have a webcam on this machine. My_Great_Skype_clone won't work optimally without one". It is not the package system's job. Or you put the capability in the app itself. My app Fontmonkey requires internet access, so it tests for it every time it starts up. My app Yabadabbadoo required 1024x768 in early revisions. I have since tweaked it to run (looks ugly, but it runs) in lower resolutions.

To be blunt, if you need to list the dependencies, the packager can easily put this in the description {} field. But why? You should be putting those in the requires {} field and the system should automagically install them, e.g. libqt4_x86. Why does the user need to know this? You can always rip the HPKG apart in Expander and read the .PackageInfo if you are a developer (note to devs: please do not remove this capability).

I do think specifying a minimum amount of RAM is a useful idea. Of course that presupposes that we have a way to test for it when developing the app. Is there a RAM-limiting utlitity out there? I can't really afford twenty computers each with a different amount of RAM on board to test a new app. With Pulse we can shut down processor cores and see if the app still runs, but how would you do that with memory? Create a RAMdisk to take up unwanted RAM, then grow it until the app stops responding?

The other way that I think the OP has a point is in graphics drivers. Especially in games, we may come to a point where we want to specify that an app is not going to do well in a VESA environment and needs a driver that talks to the GPU more directly. We're not there yet, as Pulkomandy points out, but a little future-proofing might be something to think about.

What we are missing as far as I know is a way to indicate alternatives: a given app may need a PDF viewer, but we can only specify one as a dependency. if we could say "get either BePDF or DocumentViewer" that would give us all more flexibility. If I have missed a subtlety in the packaging system, please let me know.

But those would be long-term enhancements - no need to delay a beta release for this.

[pulkomandy]

Depending on "a pdf viewer" is possible in theory. The provides/requires entries are more flexible than just the package name and cmd:/lib: entries. We only need to define a way to declare things there. It could be for example mime:application/x-pdf to declare support for a given mime type.

However, it may not be a very good idea. If you install an app that depends on "any PDF viewer", a random one will be installed by the dependency solver. Is that really what we want?

For completeness, I should also mention that there are several other entries supported in package files and currently unused for the most part. This includes things like "obsoletes" (when an app replaces another one), "complements" (for add-ons), "conflicts", etc. They would allow the dependency solver to make more informed decisions.

I like the idea of knowing that an app requires a webcam before downloading and installing it, however. Doing it post-install is already too late, I spent time downloading the app and its dependencies already (may take some time for a large app).

[michel]

I have used "conflicts" and "replaces", actually. As I learned more about packaging, I realized that some things I had packaged as "gcc2" should have been "any", that QT apps should have been indicated as "_x86" in the file name and so on. It works flawlessly. The difference between "replaces" and "obsoletes" is a bit unclear IMHO

No, I am not thinking of a random PDF reader, more something like

The package blabla.HPKG requires one of the following dependencies. Select one of the following actions:

O Option 1: Install BePDF_x86 O Option2: Install DocumentViewer_x86 O Do not install either package O Cancel Installation of blabla.HPKG Just like we handle missing dependencies now. If one of the two is already installed, it can be assumed that that is the one the user wants to use. I think the deb and rpm systems have something like this.

In the .PackageInfo it could be indicated something like this, using notation familiar from bash:

requires {
          BePDF_x86 || DocumentViewer_x86
}

Two alternatives should be a reasonable number, or three at most: we don't want to see a list of twenty text editors here.

But enough of that. let's brainstorm how we could do the hardware thing pre-installation. If we have an optional field called "hardware", in which the packager can specify certain pre-approved terms, just like we now have for "architecture" (although that one is compulsory), we could have a section like this

hardware {
          webcam
         scanner
}

the packaging system sees that entry and when the user tries to install blabla.HPKG, you get the following alert

blabla.HPG requires the following hardware to be present and functional

• A webcam
• A scanner

Please select one of the following options:

O Install blabla.HPKG O Do not install blabla.HPKG

Exactly what pieces of hardware we would allow the packager to list would be a matter for debate. Anyway, it would have to remain open-ended as new hardware comes to market. But either way, if the user wants to go ahead thinking "OK, I'll fix the webcam afterwards" that should still be possible. All you get is an alert, we're not preventing you from installing. Also, no need for the packaging system to do a hardware analysis.

That does not change my opinion that you should still put that information in the "description" field, and/or program your app accordingly, BTW.

[pulkomandy]

If we do it that way, I would say stating it in the description, and checking it at app startup, is enough. We try to avoid useless popup windows. The rationale for this is two-fold:

• Beginner users are often afraid of such messages, and never sure what to do. Is it safe to continue? Should I stop? Is it an error or just an info?
• When there are too much popup messages, experimented users train themselves to ignore them and click the "ok" button without fully reading the message.

For example in this situation, clicking the install button could result in 3 similar messages: 1) Request to select one of two possible dependencies (needs a decision) 2) Warning that some other packages will have to be updated or uninstalled (possibly harmful) 3) Notice that the software needs some particular hardware (nothing to do, just click ok)

If 3 happens often, people will get used to click ok, and when someday it is 2 instead, they will click ok and only after doing it, realize their mistake. So we should keep the popup for important cases only (2, maybe 1).

With this considered, I vote for leaving this in the package description only.

[bonefish]

Replying to pulkomandy:

However, it may not be a very good idea. If you install an app that depends on "any PDF viewer", a random one will be installed by the dependency solver. Is that really what we want?

I'm fairly sure the current implementation already asks the user in such a case.

[lelldorin]

english: It is a pity to have a debate stimulated but a pity that this goes in a completely different direction than is meant.

What I mean was actually that when I buy a software in the shop that I can see on the packaging what the use of this software requires, since is not just the hardware with meant. It makes for me for example no sense a software on a laptop with a maximum resolution of 1024x768 pixels to install, if this minimum 2028x1024 pixels needed.

Since it would be great for the user if he knows in advance what he installed on his computer and whether this makes sense at all.

I also find it wrong to say that you are not currently, because why you should always hand attachments, if you consider this from the outset and involve eventualities with. This saves a lot of double work in the future?

Since a freely definable field in a HPKG would be very practical. Since nothing has to be queried automatically, it is only about the definition of the developer who tells the user what he needs to consider when he uses his program.

258/5000 Yes, of course, there is already the description area in the package, but there will probably be described more about what a program is. Only with a defined range can the developer really suggest such an indication.

deutsch:Schön eine Debatte angeregt zu haben aber schade das diese in eine völlig andere Richtung geht als gemeint.

Gemeint von mir war eigentlich, dass wenn ich mir eine software im laden kaufe, dass ich auf der Verpackung sehen kann was die Benuzung diese software voraus setzt, da ist nicht einfach nur die Hardware mit gemeint. Es macht für mich zum Beispiel keinen sinn eine software auf einem laptop mit einer maximalen Auflösung von 1024x768 Pixel zu installieren, wenn diese Minimum 2028x1024 Pixel benötigt.

Da wäre es für den Benutzer doch toll wenn er im Vorfeld weiß was er auf seinen Rechner installiert und ob dies überhaupt sinn macht.

Ich finde es auch falsch zu sagen, dass bracht man momentan nicht, denn wieso soll man immer wieder hand an dinge anlegen, wenn man diese von vorne herein bedenkt und Eventualitäten mit einbezieht. Das erspart doch viel doppelte arbeit in der Zukunft?

Da wäre ein frei definierbares Feld in einen HPKG sehr praktisch. Da muss nichts automatisch abgefragt werden, es geht nur um die Definition des Entwicklers der dem Benutzer sagt was er bedenken muss wenn er sein Programm verwendet.

Ja natürlich gibt es bereits den beschreibungs- Bereich im Paket, aber dort wird wohl eher beschrieben um was für ein Programm es sich handelt. Nur mit einem fest definierten Bereich kann man den Entwickler wirklich nahe legen eine solche Angabe zu tätigen.

[waddlesplash]

Those kind of requirements (screen resolution, minimum RAM) from the backs of physical boxes for software have mostly gone the way of the dodo. The few applications with serious RAM requirements that convention hardware may not satisfy (e.g. high-end media editors) probably will only be installed by users that know what they are doing anyway; and indeed we can add notes in the Description as needed. So then the original "no change required" as humdinger originally set this ticket is appropriate.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed