Binärupdates von Paketen
- Ersteller Kamikaze
- Erstellt am
Das ist recht murksig. Durch +IGNOREME ist das Paket ausgeblendet. Wenn jetzt etwas auf dieses Paket eine Abhängigkeit hat, sehen diverse Port-Tools diese als nicht erfüllt an. Benötigt dies Paket andere Pakete, werden auch diese Verbindungen nicht erkannt. Gerade mit meinem Lieblingstools pkg_cutleaves kann man sich da wunderbar den Hintern wegschießen...
pkg_cutleaves ist dein Lieblingstool?
Ich finde das ja auch recht schick aber Lieblingstool ist es nicht, zudem frage ich mich mit welchen Optionen die Pakete gelöscht werden. Nur Paket weg oder alles ala -rfd. debfoster scheint mir da ein besseres Vorbild (mit "db" und -purge). Und man kann sich natürlich mit pkg_cutleaves, wie auch mit cleanlinks und und weiteren "Aufräumtools" bestens ins Knie schiessen.
Aber nichts genaues weiss ich nicht.
Ich finde das ja auch recht schick aber Lieblingstool ist es nicht, zudem frage ich mich mit welchen Optionen die Pakete gelöscht werden. Nur Paket weg oder alles ala -rfd. debfoster scheint mir da ein besseres Vorbild (mit "db" und -purge). Und man kann sich natürlich mit pkg_cutleaves, wie auch mit cleanlinks und und weiteren "Aufräumtools" bestens ins Knie schiessen.
Aber nichts genaues weiss ich nicht.
Was Abhängigkeiten angeht würde das zumindest pkg_upgrade nicht weiter stören. Das +IGNORME würde das Paket lediglich von Upgrades ausschließen, die Pakete wären immer noch gültige Abhängigkeiten und deren Liste an Abhängigkeiten würden weiterhin korrekt aktualisiert, sollte eine Abhängigkeit von pkg_upgrade ausgetauscht werden.
Die nötigen Methoden sind bereits im Rahmen des Konflikt-Handlings vorhanden.
Ich werde auch auf jeden Fall eine konfigurierbare Blacklist einbauen, das kann man dann munter kombinieren. Ich finde die +IGNOREME Sache zwar als unpraktisch aber schaden tut es auch nicht. Das wäre dann Quasi ein Akt im Dienste der Interoperabilität.
Warum nicht wie es bei freebsd-update ist, eine Kontrolle (ist das eine Kontrolle ob GENERIC genutzt wird?) ob der Release-eigene/-zugedachte Portstree genutzt wird? Dann kann z.b. mplayer (der mir auch ein definitver Kandidat für die Ports wäre; neben emacs, vim und mehr) mit Optionen aus der make.conf (oder woher auch immer) gebaut werden und es gibt kein Durcheinander...
Ergänzend: z.b. mit einem Hinweis das es ist wie es ist und das ein Portstree (evtl. ja nichtmal der komplette Tree) aus älteren Zeiten gezogen wird um passend zu bauen... Wer ältere Pakete akzeptiert hat vermutlich auch kein Problem mit einem älteren Baum. Oder so...
Ergänzend: z.b. mit einem Hinweis das es ist wie es ist und das ein Portstree (evtl. ja nichtmal der komplette Tree) aus älteren Zeiten gezogen wird um passend zu bauen... Wer ältere Pakete akzeptiert hat vermutlich auch kein Problem mit einem älteren Baum. Oder so...
Ähm. Wenn man den Release-eigenen Portstree verwendet gibt es keine Updates. Deswegen braucht man da auch keine Unterstützung von einem Update-Tool.
Da auch die Pakete aus den Ports stammen gibt es nach erfolger Installation keine Möglichkeit mehr zu erkennen, was aus den Ports ist und was fertige Pakete waren.
Da auch die Pakete aus den Ports stammen gibt es nach erfolger Installation keine Möglichkeit mehr zu erkennen, was aus den Ports ist und was fertige Pakete waren.
Ein genügsamer Mensch nutzt evtl. freebsd-update und mag dann gerne die Ports ensprechend updaten (teils u.U. mit bestimmten Optionen; mplayer ohne gtk, oder sowas). Ich dachte das sei Ziel deiner Arbeit. Einen Package-Tree der dem der aktuellen Ports enspricht wird es wohl eher nicht geben. Soweit ich das verstehe ist das auch nicht Ziel des Projekts.
Vielleicht verstehe ich auch nur vieles falsch, ich dachte solche Kunden (also die "alles fertig auf die Kiste laden"-Kunden) wolltest Du bedienen.
Vielleicht verstehe ich auch nur vieles falsch, ich dachte solche Kunden (also die "alles fertig auf die Kiste laden"-Kunden) wolltest Du bedienen.
Es gibt nur einen Ports-Tree.
Mit freebsd-update gibt es da keinen Zusammenhang, das läuft vollkommen unabhängig voneinander.
Wenn du aktuelle Pakete willst verwende einfach die stable-Pakete. Das funktioniert normalerweise. Ich habe nur einmal erlebt, dass das nicht ging, weil für einen Security-Fix die ABI gebrochen wurde. Aber selbst dann, müsst der Security-Fix ja per freebsd-update auch reinkommen.
Für die Release-Pakete gibt es überhaupt keine Updates. Nicht mal bei kritischen Sicherheitslücken.
Ich verstehe nicht wirklich wovon du redest.
Mit freebsd-update gibt es da keinen Zusammenhang, das läuft vollkommen unabhängig voneinander.
Wenn du aktuelle Pakete willst verwende einfach die stable-Pakete. Das funktioniert normalerweise. Ich habe nur einmal erlebt, dass das nicht ging, weil für einen Security-Fix die ABI gebrochen wurde. Aber selbst dann, müsst der Security-Fix ja per freebsd-update auch reinkommen.
Für die Release-Pakete gibt es überhaupt keine Updates. Nicht mal bei kritischen Sicherheitslücken.
Ich verstehe nicht wirklich wovon du redest.
vermutlich verstehe ich dann doch nicht was das Ziel deiner Arbeit ist. Ich dachte das wäre sowas wie eine Weiterführung von freebsd-update für die Ports. Wollte denken, ich habe einen Rechner auf dem ich nicht kompilieren mag (oder nicht alles) und nutze freebsd-update und dein neues Werk um im Ende den aktuellsten Release-Status zu haben.
Ich denke unter Berücksichtigung von Einträgen in der make.conf und entsprechenden Wünschen bei bestimmten Paketen (bei mir z.b. mplayer ohne gtk und skins, emacs mit x aber ohne gtk, vim ohne gtk, rxvt ... und weitere) aber gerne stabil und ohne unbedingt bleeding edge haben zu wollen wird das wirklich interessant wenn das geht.
Also sowas wie pkg_update welches guckt für was es spezielle Einstellungen gibt, für die es die packete dann aus einem passendem portstree baut.
Ich denke das derjenige der blutige Software will auch vornehmlich selber kompiliert.
Nur Überlegungen und ich will damit weder dich noch deine Arbeit schmälern.
Also sowas wie pkg_update welches guckt für was es spezielle Einstellungen gibt, für die es die packete dann aus einem passendem portstree baut.
Ich denke das derjenige der blutige Software will auch vornehmlich selber kompiliert.
Nur Überlegungen und ich will damit weder dich noch deine Arbeit schmälern.
Ich verstehe jetzt echt nicht was du meinst.
Der aktuelle Ports-Tree funktioniert tendentiell am Besten. Es gibt keinen vernünftigen Grund irgendwie etwas aus einem veralteten Ports-Tree zu bauen. Es ist nicht so als wären alte Ports besser getestet. Im gegenteil, ihnen Fehlen all die Fixes die inzwischen dazugekommen sind. Der konservative Ansatz ist also den aktuellen Tree zu verwenden.
Bei den FreeBSD Ports gibt es CURRENT oder Stillstand. Alles dazwischen sind Hirngespinste die aus Überlegungen stammen die auf FreeBSD nicht anwendbar sind, weil sie aus den Konzepten anderer Paketsysteme kommen.
Du bist da anscheinend vorbelastet und hast vollkommen falsche Vorstellungen von den FreeBSD Ports und Paketen.
Der aktuelle Ports-Tree funktioniert tendentiell am Besten. Es gibt keinen vernünftigen Grund irgendwie etwas aus einem veralteten Ports-Tree zu bauen. Es ist nicht so als wären alte Ports besser getestet. Im gegenteil, ihnen Fehlen all die Fixes die inzwischen dazugekommen sind. Der konservative Ansatz ist also den aktuellen Tree zu verwenden.
Bei den FreeBSD Ports gibt es CURRENT oder Stillstand. Alles dazwischen sind Hirngespinste die aus Überlegungen stammen die auf FreeBSD nicht anwendbar sind, weil sie aus den Konzepten anderer Paketsysteme kommen.
Du bist da anscheinend vorbelastet und hast vollkommen falsche Vorstellungen von den FreeBSD Ports und Paketen.
pit234a
Well-Known Member
danach: rm -rf /usr/ports/packages/All ?
das ist hier am 16.04.2009 so gestartet worden, wenn ich recht sehe und heute, am 03.06.2009, habe ich da mal ein wenig gelesen.
Es schien mir nicht sehr erstrebenswert, ein Tool zu bekommen, das einem Pakete installiert. So was gibt es ja schon und wo Pakete fehlen, wird auch dieses Tool versagen müssen.
Nun habe ich einen Rechner, einen file-server (von dem ich hier schon mehrfach erzählte) und da will ich nur ganz bestimmte Sachen und recht wenig installieren und da wäre ein kompletter Ports-Tree überhaupt nicht angesagt.
Alles, was darauf ist, wurde als Paket drauf geschoben und wenn ich was nicht direkt finden konnte, baute ich das auf meinem Arbeitsrechner selbst mit pkg_create -b. Das ging so gut.
Freebsd-update besorgte mir die Updates des Systems, aber ich fragte mich schon, wie das nun mit dem Paketen denn weitergehen würde.
Nun habe ich eben die bsdadminscripts-6.1.1 auf meinem Arbeistrechner als Paket gebaut und dem Fileserver installiert und lasse ein erstes pkg_upgrade -a laufen.
Das ist schon mal gut, es wird kein Ports-Tree gezogen und angelegt, ganz, wie hier beschrieben.
/var/db/uma/FTPINDEX 100% of 16 MB
zeigt, daß dieser Index auch nicht ganz klein ist, om Vergleich zum Ports-Tree geht er aber ratz-fatz rein.
Auch gut ist, daß nun erst mal die benötigten Pakete geladen werden und zwar nach /usr/ports/packages/All, das es zuvor noch gar nicht gab.
Nun updatet dieser Rechner erst mal, doch ich frage mich bereits, wie werde ich den Ballast wieder los?
portsclean gibt es ja nun auch nicht.
Ist es sauber, die Pakete einfach zu löschen? Oder das Verzeichnis?
das ist hier am 16.04.2009 so gestartet worden, wenn ich recht sehe und heute, am 03.06.2009, habe ich da mal ein wenig gelesen.
Es schien mir nicht sehr erstrebenswert, ein Tool zu bekommen, das einem Pakete installiert. So was gibt es ja schon und wo Pakete fehlen, wird auch dieses Tool versagen müssen.
Nun habe ich einen Rechner, einen file-server (von dem ich hier schon mehrfach erzählte) und da will ich nur ganz bestimmte Sachen und recht wenig installieren und da wäre ein kompletter Ports-Tree überhaupt nicht angesagt.
Alles, was darauf ist, wurde als Paket drauf geschoben und wenn ich was nicht direkt finden konnte, baute ich das auf meinem Arbeitsrechner selbst mit pkg_create -b. Das ging so gut.
Freebsd-update besorgte mir die Updates des Systems, aber ich fragte mich schon, wie das nun mit dem Paketen denn weitergehen würde.
Nun habe ich eben die bsdadminscripts-6.1.1 auf meinem Arbeistrechner als Paket gebaut und dem Fileserver installiert und lasse ein erstes pkg_upgrade -a laufen.
Das ist schon mal gut, es wird kein Ports-Tree gezogen und angelegt, ganz, wie hier beschrieben.
/var/db/uma/FTPINDEX 100% of 16 MB
zeigt, daß dieser Index auch nicht ganz klein ist, om Vergleich zum Ports-Tree geht er aber ratz-fatz rein.
Auch gut ist, daß nun erst mal die benötigten Pakete geladen werden und zwar nach /usr/ports/packages/All, das es zuvor noch gar nicht gab.
Nun updatet dieser Rechner erst mal, doch ich frage mich bereits, wie werde ich den Ballast wieder los?
portsclean gibt es ja nun auch nicht.
Ist es sauber, die Pakete einfach zu löschen? Oder das Verzeichnis?
pit234a
Well-Known Member
Ah ja, hatte ich beinahe übersehen, obwohl in der man page ausdrücklich beschrieben.
Also, eine ganz super Sache dieses script und sehr nützlich und, auch das mal angemerkt, vorbildlich beschrieben.
Herzlichen Dank.
Vielen Dank.
Die Features, die noch in die nächste Version sollen, wachsen mir schon wieder über den Kopf und schieben die langfristig geplanten Features, die ich implementieren will, wenn das Feedback versiegt (womit ich dann davon ausgehe, dass die aktuellen Features den Wünschen der Nutzer entsprechend funktionieren), zurück.
So wie ich das sehe kann das Skript durch all die Rückmeldungen ja nur besser werden. Nur schade, dass es den MOVED file von Pointyhead wahrscheinlich nie geben wird.
Die Features, die noch in die nächste Version sollen, wachsen mir schon wieder über den Kopf und schieben die langfristig geplanten Features, die ich implementieren will, wenn das Feedback versiegt (womit ich dann davon ausgehe, dass die aktuellen Features den Wünschen der Nutzer entsprechend funktionieren), zurück.
So wie ich das sehe kann das Skript durch all die Rückmeldungen ja nur besser werden. Nur schade, dass es den MOVED file von Pointyhead wahrscheinlich nie geben wird.
Moin,
wenn ich den Sinn von pkg_upgrade richtig verstanden habe, ist das Programm genau das, was ich gerade brauche. Jedoch stehe ich vor dem Problem, dass ich das Programm für FreeBSD-6.4 bräuchte. Bevor ich jetzt versuche da irgendwie ran zu kommen, habe ich eine Frage, deren Antwort ich beim Lesen des Threads vermutlich übersehen habe:
Ich würde stable-packages nutzen wollen, was ich dem System auch sagen könnte. Verstehe ich das richtig, dass pkg_upgrade über die gesetzte PACKAGESITE prüft ob neue Pakete da sind und die dann installiert? Eigentlich wollte ich ja keine stable-packages verweden, was aber vermutlich sinnbefreit ist... Aktuell werde ich aber "gezwungen", da pidgin in der installierten Version so nicht mehr funktioniert (Protokolländerung).
Gruß
wenn ich den Sinn von pkg_upgrade richtig verstanden habe, ist das Programm genau das, was ich gerade brauche. Jedoch stehe ich vor dem Problem, dass ich das Programm für FreeBSD-6.4 bräuchte. Bevor ich jetzt versuche da irgendwie ran zu kommen, habe ich eine Frage, deren Antwort ich beim Lesen des Threads vermutlich übersehen habe:
Ich würde stable-packages nutzen wollen, was ich dem System auch sagen könnte. Verstehe ich das richtig, dass pkg_upgrade über die gesetzte PACKAGESITE prüft ob neue Pakete da sind und die dann installiert? Eigentlich wollte ich ja keine stable-packages verweden, was aber vermutlich sinnbefreit ist... Aktuell werde ich aber "gezwungen", da pidgin in der installierten Version so nicht mehr funktioniert (Protokolländerung).
Gruß
pit234a
Well-Known Member
bin gerade auch dabei, solch einen Update auf einem 6-RC1 System zu machen und habe damit aber ein paar Probleme.
Zunächst: das Script ist in bsd-admin-scripts enthalten (Schreibweise nicht geprüft) und die findest du in den ports und kannst sie mit pkg-add -r einbauen. Deine PACKAGESITE setzte du im Environment, bei mir über einen setenv-Eintrag in der csh.cshrc. Auch ich habe da stable bei der 6er genommen.
Ein erstes Problem war kdm. Ich nutze KDE3 und kdm ist Bestandteil von kdebase3 und wollte nicht mehr, mit einer Fehlermeldung, die letztlich den Schluß zuließ, daß diese binary defekt ist. Es blieb mir also nicht anderes übrig, als doch die Ports zu ziehen und dieses dann so zu beheben.
Außerdem funktioniert meine Maus unter X nun nicht mehr. (Seltsamerweise nach einen Stromausfall-bedingten Abbruch bei einem make install). Alle Versuche bisher halfen nichts und nun will ich gerade auch das Basis-System updaten, weil vielleicht die RC1 doch nicht alles kann, was gefordert wird.
Vermutlich hätte ich schneller neu installiert gehabt.
pkg_upgrade lief aber problemlos.
Es findet seinen Überblick in einer Datei auf einem extra Server, den Soul-Rebell betreibt und wo er und Kamikaze gemeinsam diese Datei am leben halten. So weit ich verstanden habe, sieht es also nicht in der PACKAGESITE nach.
Zunächst: das Script ist in bsd-admin-scripts enthalten (Schreibweise nicht geprüft) und die findest du in den ports und kannst sie mit pkg-add -r einbauen. Deine PACKAGESITE setzte du im Environment, bei mir über einen setenv-Eintrag in der csh.cshrc. Auch ich habe da stable bei der 6er genommen.
Ein erstes Problem war kdm. Ich nutze KDE3 und kdm ist Bestandteil von kdebase3 und wollte nicht mehr, mit einer Fehlermeldung, die letztlich den Schluß zuließ, daß diese binary defekt ist. Es blieb mir also nicht anderes übrig, als doch die Ports zu ziehen und dieses dann so zu beheben.
Außerdem funktioniert meine Maus unter X nun nicht mehr. (Seltsamerweise nach einen Stromausfall-bedingten Abbruch bei einem make install). Alle Versuche bisher halfen nichts und nun will ich gerade auch das Basis-System updaten, weil vielleicht die RC1 doch nicht alles kann, was gefordert wird.
Vermutlich hätte ich schneller neu installiert gehabt.
pkg_upgrade lief aber problemlos.
Es findet seinen Überblick in einer Datei auf einem extra Server, den Soul-Rebell betreibt und wo er und Kamikaze gemeinsam diese Datei am leben halten. So weit ich verstanden habe, sieht es also nicht in der PACKAGESITE nach.
Das das Script in "bsdadminscripts" liegt, ist mir bekannt (natürlich trotzdem danke für die Info). Das Problem ist, dass ich dafür einen Portstree brauche, da es natürlich noch nicht in den Packages für 6.4 enthalten ist. Das Script jedoch hat ja genau den Vorteil, dass man den Portstree NICHT braucht (was ich auf der Kiste auch nicht haben möchte)
Das hat aber nicht zufällig mit dem ach so tollen hal/X-7.4-Problem zu tun?
Gruß
Edit: Kleiner Nachtrag: bsdadminscripts ist in der Version 6.1.1 bei den stable-packages enthalten. GEIL!
pit234a
Well-Known Member
ftp://ftp.freebsd.ch/pub/FreeBSD/ports/i386/packages-6-stable/All/bsdadminscripts-6.1.1.tbz
genau, wollte ich dir gerade schreiben, daß ich es da auch gefunden hatte.
Das Maus-Problem sieht genau aus, wie diese hal/X-7.4 Geschichte, nur, daß ich alles durchprobiert habe, was ich in dem Zusammenhang bisher fand und nichts hat bislang etwas geändert. Es funktioniert auf neu installierten System, es schient nur kritisch bei updates zu sein und vielleicht hat mir irgendwas durch diesen leidigen Stromausfall zusätzlich was verhagelt. Es sieht alles so aus, wie es sollte, hal und Konsorten laufen, die .fdi liegen am rechten Platz und haben passenden Inhalt, die xorg.conf habe ich mit und ohne AllowEmpty... gehabt und alles hat bisher nichts geholfen. Deshalb versuche ich nun mal den Update auf eine neuere Version der Basis.
genau, wollte ich dir gerade schreiben, daß ich es da auch gefunden hatte.
Das Maus-Problem sieht genau aus, wie diese hal/X-7.4 Geschichte, nur, daß ich alles durchprobiert habe, was ich in dem Zusammenhang bisher fand und nichts hat bislang etwas geändert. Es funktioniert auf neu installierten System, es schient nur kritisch bei updates zu sein und vielleicht hat mir irgendwas durch diesen leidigen Stromausfall zusätzlich was verhagelt. Es sieht alles so aus, wie es sollte, hal und Konsorten laufen, die .fdi liegen am rechten Platz und haben passenden Inhalt, die xorg.conf habe ich mit und ohne AllowEmpty... gehabt und alles hat bisher nichts geholfen. Deshalb versuche ich nun mal den Update auf eine neuere Version der Basis.
So, nur so zur Info.
Das sammeln von pkg-messages funktioniert jetzt, genau so wie das auflisten beschädigter Pakete (optional ebenfalls in einer Datei).
Am Installieren aus Dateien arbeite ich noch. Das funktioniert zwar inzwischen aber die Sache fühlt sich noch nicht sauber an.
Das Problem ist, dass ich bei der Entwicklung von einem konsistenten Index ausgegangen bin. Pakete aus Dateien machen in diesem Sinn alles kaputt und können an allen Ecken und Enden Inkonsistenzen verursachen, die ich erkennen und korrigieren muss.
Kurz gesagt, ich muss den ganzen Code mit Ausnahmen durchziehen. Und ich überlege ob ich das vielleicht wegkapsle um die eigentliche Logik nicht damit aufzublähen.
Objektorientiert wäre das alles einfacher, aber mit /bin/sh als Interpreter ist Objektorientierte Programmierung einfach nur Panne.
Das sammeln von pkg-messages funktioniert jetzt, genau so wie das auflisten beschädigter Pakete (optional ebenfalls in einer Datei).
Am Installieren aus Dateien arbeite ich noch. Das funktioniert zwar inzwischen aber die Sache fühlt sich noch nicht sauber an.
Das Problem ist, dass ich bei der Entwicklung von einem konsistenten Index ausgegangen bin. Pakete aus Dateien machen in diesem Sinn alles kaputt und können an allen Ecken und Enden Inkonsistenzen verursachen, die ich erkennen und korrigieren muss.
Kurz gesagt, ich muss den ganzen Code mit Ausnahmen durchziehen. Und ich überlege ob ich das vielleicht wegkapsle um die eigentliche Logik nicht damit aufzublähen.
Objektorientiert wäre das alles einfacher, aber mit /bin/sh als Interpreter ist Objektorientierte Programmierung einfach nur Panne.
Hm, irgendwie läuft hier was schief. Wenn ich pkg_upgrade -a (unter FreeBSD-6.4/i386) aufrufe, dann prüft er nur ein paar X-Pakete und aktualisiert nichts, obwohl ich davon ausgehe, dass es ein paar neue Pakete geben sollte.
Selbst wenn es keine gibt, geht mir das irgendwie zu schnell, da der erste Durchlauf ewig gebraucht hatte.
Edit: Ok. Vermutlich ein Schnellschuss. Ich habe das letzte Update wohl am 13.06. laufen lassen (sagt das logfile), der FTPINDEX ist vom 11.06.
Selbst wenn es keine gibt, geht mir das irgendwie zu schnell, da der erste Durchlauf ewig gebraucht hatte.
Edit: Ok. Vermutlich ein Schnellschuss. Ich habe das letzte Update wohl am 13.06. laufen lassen (sagt das logfile), der FTPINDEX ist vom 11.06.
Zuletzt bearbeitet:
Nur so für die Interessierten,
ich habe zwar die Features, die ich mir für diese Version vorgenommen haben, erfolgreich implementiert und sie scheinen gut zu funktionieren. Aber mir fehlt das vertrauen in die Sache. Die Funktionen sind zu groß geworden und zu weit verzweigt ich kann mir kaum vorstellen, dass das zuverlässig läuft.
Deshalb habe ich heute angefangen Teile des Skripts objektorientiert zu reimplementieren. Ich habe mal ein paar Funktionen aus denen man Objekte basteln kann gebaut, nur einen Konstruktor, Destruktor, Getter und Setter.
Ich habe zuerst befürchtet, dass mir der Overhead das Genick brechen wird, aber nach den ersten Versuchen damit gehe ich davon aus, dass der Effekt zumindest teilweise durch das Vermeiden von Redundanzen und schneller Vergleiche wieder wett gemacht wird.
Ich kann so ca. 1000 Objekte pro Sekunde anlegen (natürlich je nach Beschaffenheit des Konstruktors), das Löschen geht noch schneller. Ich denke damit kann man arbeiten.
ich habe zwar die Features, die ich mir für diese Version vorgenommen haben, erfolgreich implementiert und sie scheinen gut zu funktionieren. Aber mir fehlt das vertrauen in die Sache. Die Funktionen sind zu groß geworden und zu weit verzweigt ich kann mir kaum vorstellen, dass das zuverlässig läuft.
Deshalb habe ich heute angefangen Teile des Skripts objektorientiert zu reimplementieren. Ich habe mal ein paar Funktionen aus denen man Objekte basteln kann gebaut, nur einen Konstruktor, Destruktor, Getter und Setter.
Ich habe zuerst befürchtet, dass mir der Overhead das Genick brechen wird, aber nach den ersten Versuchen damit gehe ich davon aus, dass der Effekt zumindest teilweise durch das Vermeiden von Redundanzen und schneller Vergleiche wieder wett gemacht wird.
Ich kann so ca. 1000 Objekte pro Sekunde anlegen (natürlich je nach Beschaffenheit des Konstruktors), das Löschen geht noch schneller. Ich denke damit kann man arbeiten.
Es ist wohl an der Zeit für einen kleinen Zwischenbericht.
Inzwischen habe ich mit der objektorientierten teilweise-Reimplementierung begonnen. Im tatsächlichen Gebrauch ist das Objekt-Framework noch mal deutlich gewachsen. Besonders stolz bin ich darauf, dass Methoden Daten in den Kontext des Aufrufers zurückliefern können ohne auf globale Variablen oder echo zurückzugreifen. Der Aufrufer muss lediglich den Namen seiner Variable übergeben, der darf sich dann sogar mit einer in der Methode lokalen Variable überdecken.
Der Overhead erhöht sich mit all dem natürlich nochmal deutlich, ob durch das Einsparen von Redundanzen und Lazy-Access (Objekte besorgen sich ihre Daten erst wenn sie tatsächlich benötigt werden, mehr Programmieraufwand, weniger Speicher und CPU-Bedarf da das unnötige verarbeiten von Daten vermieden wird) dieser Nachteil ausgeglichen werden kann wird wohl erst das fertige Programm zeigen.
Inzwischen hat sich das FreeBSD portmgr-Team der PRs von soul_rebel (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/131440) und mir (http://www.freebsd.org/cgi/query-pr.cgi?pr=135024) angenommen. Ich gehe davon aus bis die Änderungen auf alle Build-Server und zu Tinderbox vordringen wird noch einige Zeit vergehen. Aber die Zukunft für Binäre Paketverwaltung unter FreeBSD sieht für mich jetzt ganz vielversprechend aus.
Inzwischen habe ich mit der objektorientierten teilweise-Reimplementierung begonnen. Im tatsächlichen Gebrauch ist das Objekt-Framework noch mal deutlich gewachsen. Besonders stolz bin ich darauf, dass Methoden Daten in den Kontext des Aufrufers zurückliefern können ohne auf globale Variablen oder echo zurückzugreifen. Der Aufrufer muss lediglich den Namen seiner Variable übergeben, der darf sich dann sogar mit einer in der Methode lokalen Variable überdecken.
Der Overhead erhöht sich mit all dem natürlich nochmal deutlich, ob durch das Einsparen von Redundanzen und Lazy-Access (Objekte besorgen sich ihre Daten erst wenn sie tatsächlich benötigt werden, mehr Programmieraufwand, weniger Speicher und CPU-Bedarf da das unnötige verarbeiten von Daten vermieden wird) dieser Nachteil ausgeglichen werden kann wird wohl erst das fertige Programm zeigen.
Inzwischen hat sich das FreeBSD portmgr-Team der PRs von soul_rebel (http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/131440) und mir (http://www.freebsd.org/cgi/query-pr.cgi?pr=135024) angenommen. Ich gehe davon aus bis die Änderungen auf alle Build-Server und zu Tinderbox vordringen wird noch einige Zeit vergehen. Aber die Zukunft für Binäre Paketverwaltung unter FreeBSD sieht für mich jetzt ganz vielversprechend aus.