Ich finde die Linux-Ports kommen in sehr unterschiedlicher Qualität daher, deshalb will ich eine Metrik etablieren, um zumindest Klarheit bezüglich Kompatibilität punkto Distros zu schaffen - wer kennt das nicht, wenn plötzlich die eigene libc plötzlich angeblich zu alt, ist, obwohl es sich tatsächlich nur um eine reine binär-aufwärts inkompatibilität handelt und eigentlich nie um eine source level oder funktionale inkompatibilität handelt, also eigentlich völlig ahnungslose entwickler, die einfach nicht begriffen haben das richtige buildsystem zu wählen - böse gesagt.
Ich schlage daher eine Liste qualitativer Eigenschaften vor, die ich gleichvorstellen werden, die dann unter gewichtung klipp und klar sagen, ob ein port sehr schlecht, schlecht, ungenügend, genügend, gut, sehr gut ist. Damit können wir die Spiele ähnlich der winehq appdb bewerten. Was findet ihr? Wäre das ein gutes enhancement für holarse wenn man das für jedes spiel sehen kann?
edit: So
Mein Tablet-Deutsch ist katastrophal, sorry :-)
Nun die Liste:
repository: Der Hersteller bietet Updates via Standard-Repository (deb, rpm) an
tarball: Der Hersteller bietet einen tarball, der an beliebiger Stelle entpackt werden kann, an
non-root-installer: Der Hersteller bietet einen Installer an, der nicht als root ausgeführt werden muss (optional darf der Installer natürlich Abhängigkeiten z.B. via PackageKit einfordern, aber dem User muss erlaubt sein, dies selbst zu tun) - in diese kategorie gehen auch Plattformen wie Steam und Desura
consumer-long-term: Binärkompatibel zu allen(1) Long-Term Linux-Distributionen (Debian und Ubuntu, gibt es weitere? - bitte nennen)
consumer-long-and-short-term: Binärkompatibel zu allen(1) Long-Term und Short-Term Distributionen
total-long-term: Absolut alle(1) Long-Term Linux-Distributionen werden unterstützt, auch Enterprise Distributionen (Red Hat & Derivate wie CentOS)
total-long-and-short-term: Absolut alle(1) Linux-Distributionen werden unterstützt
one-binary-for-all: Alle Distributionen verwenden dasselbe binary (Das ist eine Eigenschaft, die für den Anwender nicht direkt bemerkbar ist, aber für die Generizität des Builds spricht und positiv zu bewerten ist)
minimum-self-provided-dependencies: Wie one-binary-for-all spricht es für die Generizität und Bedachtheit der Entwickler. Es heisst, dass die Entwickler möglichst keine Bibliotheken mitbringen, die in den Paketsystemen der Distributionen schon enthalten sind
oldstable: Es werden alle noch unterstützten Long-Term-Versionen unterstützt
Die Eigenschaften sind verschieden wichtig und können verschieden ausgeprägt sein - so kann ein repository nur für Ubuntu existieren und alle anderen Distributionen müssen mit einem tarball leben - oder für absolut alle Distributionen gibt es ein Repository, aber auch einen tarball.
Als genügend wird es betrachtet, wenn mindestens folgendes erfüllt ist:
(tarball || non-root-installer) && consumer-long-term
sehr schlecht wäre wenn keine eigenschaften erfüllt würden: Es gibt einen Installer der root erfordert, nur unter Ubuntu läuft, aber nicht auf Debian.
Sehr gut wäre als Beispiel:
Es gibt für jede Distribution ein Repository, es gibt aber auch einen tarball und einen installer, womit man ins Home-Verzeichnis installieren kann, CentOS 5 ist auch noch unterstützt, das Spiel liefert keine Bibliotheken mit. Das Executable für CentOS 5 ist dasselbe wie das Executable für Arch & gentoo.
(1)Wenn ein OS A Binärkompatibiliät zu einem anderen OS B garantiert (z.B. Mint zu Ubuntu oder Oracle Linux zu Red Hat) und keine Ausnahme macht (z.B. kommerzieller Teil des Ubuntu Software-Center in Mint), dann muss eine Anwendung nur unter OS A getestet sein, um als lauffähig unter OS B zu gelten.
Übrigens: Wenn ein Spiel Abhängigkeiten erfordert, die nicht OOTB in der Distribution enthalten sind, aber sehr wohl in den offiziellen Repositories der Distribution, dann ist das nicht im geringsten ein Minus-Punkt für das Spiel, schliesslich haben Distributionen sowieso minimal zu sein und alle Abhängigkeiten möglichst "lazy" zu installieren. Es hat einen Grund warum wir Package Management verwenden und nicht old school ROMs.
