Man kann darüber streiten, ob nun die Unterstützung von Grafik und ihrer Beschleunigung wirklich wichtig sind und ob es nicht sogar als SW von Dritten sowieso überhaupt gar nichts mit FreeBSD zu tun hat.
Wobei diese Diskussion eine eher theoretische ist. Es ist ja weniger die Frage, ob was zum System dazu gehört oder nicht. Es ist eher die Frage, hat jemand die Zeit sich darum zu kümmern.
störte mich diese Ungereimtheit nun besonders und ich finde es nach wie vor unglücklich.
Ist ja durchaus verständlich.
Nur das macht ja niemand, um Nutzer wie Dich zu ärgern.
Die FreeBSD-Leute wollen solche Fehler auch nicht. Und wenns mal doch dazu kommt, würden sie die natürlich auch gern fixen.
Vielleicht findet sich dann eine allgemeine Lösung über Pakete, also, im Grunde bräuchte man ja nur das entstehende Paket in einem 12.2 mit einem neuen Namen zu versehen und schon hätte man das.
Das ist ein schönes Beispiel dafür, das Dinge zwar erst mal einfach scheinen, aber in Wirklichkeit dann doch nicht sind. :-)
Also ja. Im Prinzip könnte man einfach ein Paket
drm-fbsd12.2-kmod machen. Aber was sind die Implikationen? Man möchte ja auch bei zukünftigen FreeBSD-Versionen einfach updaten können.
Deswegen gibts ja auch das
drm-kmod-Package, was man nehmen soll und was je nach FreeBSD-Version das entsprechende Package als Abhängigkeit hat.
Wie sieht es bei den Ports aus und warum funktioniert das mit der Versionsabhängigkeit da?
Der
drm-kmod-Port macht ja eine explizite Abfrage der FreeBSD-Versionsnummer und gestaltet danach seine Abhängigkeit (wie im obigen Posting von mir dargestellt).
Wenn man da eine weitere FreeBSD-Version unterstützen will braucht man nur zwei Zeilen anfügen die dann auf den entsprechend abhängigen Port verweisen und gut ist.
In dem Package
drm-kmod was Du baust ist aber eine solche Abfrage nicht drin. Da ist die Abhängigkeit dann fest verdrahtet. Und da es keine unterschiedlichen Paket-Repositories für verschiedene Unterversionen von FreeBSD gibt (sondern nur für die Hauptversionen), hast Du halt dann ein Problem.
Das ließe sich auch durchaus lösen. Man könnte z.B. auch das Package mit nem Packagescript ausstatten was eine Versionsabfrage vornimmt und dann daraus das entsprechend abhängige Package wählt. Aber bisher gibt es das nicht. Das bedeutet, das Problem ist eben nicht trivial und "mal eben" zu lösen, sondern bedarf schon eines kleinen Mehraufwandes. Und dann sind wir wieder bei dem Problem: Wer hat Zeit für sowas
Was man noch machen könnte wäre eine Art Dirty-Hack. Man sagt sich einfach: Wir bauen so ein Paket und stellen es zur Verfügung und der Benutzer muss es dann explizit installieren.
Das heißt aber letztlich auf alles Sch***en was so das Abhäbngigkeits und Upgrade-Management angeht und wo man spätestens beim nächsten Upgrade die User wieder in Probleme laufen lässt.
Das ist halt das blöde daran. Wenn man so ein Package baut, muss man es auch längerfristig supporten.
Bedeutet auch wieder Aufwand. Auch wieder die Frage: Wer hat Zeit für sowas?
Ich hoffe, ich konnte einigermaßen anschaulich darstellen, wo das Problem liegt und warum es nicht leicht zu fixen ist. Ist zugegebenermaßen nicht einfach zu verstehen. :-)
Mal sehen, wie ich lustig bin.
Also wenn man ein vorsichtiger Nutzer ist, dann ist es sicher nicht verkehrt sich Zeit zu lassen mit Upgrades. Über kurz oder lang wird ja mit den Packages alles wieder funktionieren. Spätestens wenn, wie oben angemerkt, 12.1 End-of-Life ist und daher solche Packages durch gegen 12.2 kompilierte Packages ersetzt sind.
Und gerade für Notfallsysteme besteht ja auch kein Druck die zeitnah irgendwie hochziehen zu müssen.