Suche Möglichkeit Versionen von Programmen/Libraries auf Aktualität zu prüfen?

Harry3

unregistriert
Thread Starter
Dabei seit
19.04.2014
Beiträge
157
Reaktionspunkte
0
Hi,

habe inzwischen das eine oder andere Skript erstellt mit dem ich mir verschiedene Tools selber kompiliere, habe aber das Problem dass es inzwischen etliche (über 60) Libraries/Binaries gibt die ich gelegentlich auf Aktualität prüfen müsste. Gibt es da ein Programm welches überprüft was die aktuelle Version einzelner Libraries/Binaries ist? Oder eine Liste die man abfragen kann? Evtl. eine Liste einer großen aktuellen Linux-Distribution?

Ein paar Beispiele sind: boost, wxwdigets, freetype, fontconfig, pkg-config, autoconf, automake, ruby, git, sdl, ...
 
Am einfachsten wäre dafür wohl einen Port Manager wie MacPorts oder Hombrew zu benutzen.
 
Am einfachsten wäre dafür wohl einen Port Manager wie MacPorts oder Hombrew zu benutzen.
Sorry, aber diese Standard-Antwort ist genau so anstrengend wie die Antwort "Spiele dein TimeMachine-Backup wieder ein" wenn jemand über Probleme mit der HDD schreibt. Abgesehen davon habe ich die Frage auch schon mehrfach im ffmpeg-Thread beantwortet. Und die einfachste Antwort ist: es gibt eben nicht für alles Lösungen via brew oder MacPorts! Die gleichen Probleme hatte ich früher auch mit fink, so dass ich irgendwann angefangen habe mir die Dinge die ich selber brauche, selber zu kompilieren.
 
Die Autoren der Software geben das Erscheinen neuer Versionen bekannt, in der Regel durch mailinglists (meistens: announce). Du könntest dich also einfach per Mail informieren lassen. Linux Distributionen geben Änderungen oftmals auch durch mailinglists bekannt. Da gibt es aber einige Fallstricke: Distributionen verwenden teilweise (bewusst) nicht die neuerste upstream Version, patchen aber dafür eine ältere, insbesondere hinsichtlich security updates. (Pakete aus Debian stable werden dir z.B. nicht weiterhelfen.)
Ein damit verbundenes Problem: eine neue Version vom Paket foo ist verfügbar. 1.0.0.4. Und was bedeutet das für dich? Aufwand. Ein Programm könnte nur mit foo < 1.0.0.4 funktionieren/getestet sein. Du musst also auch alle Abhängigkeiten manuell auflösen. (Heisst jedes mal manuell linken oder gar kompilieren, und zwar jedes Programm einzeln mit der jeweils richtigen Version des Paketes foo. Und ganz bitter wird es, wenn das Programm eine gepachte Version eines Paketes benötigt. Das wird unglaublich schnell unglaublich unübersichtlich.) Gut gemeinte Kritik bevor deine Software Sammlung wächst und wächst: rechne das durch. 5 Pakete die jeweils bestimmte ältere Versionen benötigen, die jeweils bestimmte ältere Ver… . Been there, done that.
Als nächstes wird es dir wahrscheinlich auf die Nerven gehen, die Pakete einzeln zu laden und die checksums und signatures manuell abzugleichen. Dann automatisierst du auch das. Siehst du wo das hinführt? Hast du überprüft, ob nicht eine bereits bestehende Paketverwaltung dir die Möglichkeit bietet, ein eigenes "build script" lokal aber innerhalb dessen Ökosystems zu verwenden? Dann wäre meiner Meinung nach genau wonach du suchst.
Mein Tipp: nur das aller nötigste selbst bauen. Oder aber ein Betriebssystem mit einer flexiblen Paketverwaltung verwenden. Alles andere ist unpraktisch und macht kaum jemand auf Dauer.
 
Sorry, aber diese Standard-Antwort ist genau so anstrengend wie die Antwort "Spiele dein TimeMachine-Backup wieder ein" wenn jemand über Probleme mit der HDD schreibt. Abgesehen davon habe ich die Frage auch schon mehrfach im ffmpeg-Thread beantwortet.

1. Welche Frage? Ich habe keine Frage gestellt, ich habe dir einen Vorschlag gemacht.
2. Du erwartest nicht ernsthaft, dass jeder zuerst all deine anderen Threads liest, bevor er eine Antwort postet, oder? ;) Schreib doch das nächste Mal einfach kurz, dass du solche Tools bereits ausgeschlossen hast. Damit sparst du dir und mir und allen anderen wertvolle Zeit. :)

Nix für ungut... :)
 
Sorry, aber diese Standard-Antwort ist genau so anstrengend wie die Antwort "Spiele dein TimeMachine-Backup wieder ein" wenn jemand über Probleme mit der HDD schreibt. Abgesehen davon habe ich die Frage auch schon mehrfach im ffmpeg-Thread beantwortet. Und die einfachste Antwort ist: es gibt eben nicht für alles Lösungen via brew oder MacPorts! Die gleichen Probleme hatte ich früher auch mit fink, so dass ich irgendwann angefangen habe mir die Dinge die ich selber brauche, selber zu kompilieren.

naja, so schlecht ist die Antwort nun auch wieder nicht. Es macht eigentlich keine allzu große Arbeit, mit MacPorts dir deine eigenen kleinen Portfiles zu schreiben und darin dann halt auch mit den diversen livecheck.* Anweisungen die website des source-Projektes zu parsen. Da reicht dann ein 'port livecheck <portname>' und du kriegst alle neueren Versionen des Packets 'portname' einschließlich aller dependencies.

Gut, du musst dich in MacPorts und die Syntax der Portfiles bzw Tcl einarbeiten, aber wenn du so wie du schreibst ja viel selbst kompilierst (ich hoffe mal mehr als nur ./configure; make; make install) dann ist das kein Thema. Und glaub mir, ich weiss wovon ich rede. Ich mache das seit Jahren genauso indem ich GIMP on OS X maintaine. Und ne flexiblere und modularere Lösung als Macports habe ich für das checken nach updates noch nicht gefunden.

Also, nicht gleich bei ner Antwort, die du nicht probiert hast gleich los legen und drauf hauen, sondern ruhig mal hinterfragen und eventuell sogar einlesen und testen.

lisanet

(a.k.a. skl)
 
aber wenn du so wie du schreibst ja viel selbst kompilierst (ich hoffe mal mehr als nur ./configure; make; make install) dann ist das kein Thema.
Was ist kompilieren viel mehr als configure, make, make install?

Ich mache das seit Jahren genauso indem ich GIMP on OS X maintaine.
Finde ich absolut klasse dass du dir die Arbeit machst und andere Nutzer daran teilhaben lässt!

Also, nicht gleich bei ner Antwort, die du nicht probiert hast gleich los legen und drauf hauen, sondern ruhig mal hinterfragen und eventuell sogar einlesen und testen.
Ich habe Fink schon zu PPC-Zeiten genutzt und war bisher weder mit Fink, MacPorts noch brew länger zufrieden. Mich stört aber an dem Antwortstil (von 3 der 4 Antworten) dass überhaupt nicht auf die Frage eingegangen wird sondern versucht wird von etwas anderem zu überzeugen. Aber hier im Forum hat es sich scheinbar eingebürgert.
 
Mich stört aber an dem Antwortstil (von 3 der 4 Antworten) dass überhaupt nicht auf die Frage eingegangen wird sondern versucht wird von etwas anderem zu überzeugen. Aber hier im Forum hat es sich scheinbar eingebürgert.
Das ist eben ein ergebnisorientierter Ansatz, der bei sehr vielen Fragen hier im Forum durchaus sinnvoller ist als eine mögliche präzise Anwor, die aber vielleicht zu anderen Problemen führt, umständlich ist oder sonstwie problematisch.
Gibt den alten Cowboywitz:
"Was hast du deinem Pferd gegeben, als es neulich diese Kolik hatte?"
"Petroleum."
[Man beachte: eine kurze und präzise Anwort]
Zwei Wochen treffen sie sich wieder.
"Mein Pferd is eingegangen, als ich ihm Petroleum zu saufen gab."
"Jou, meins auch."

Dagegen würde helfen, schon im Ausgangspost detailliert zu erwähnen, was man weiß und kann und versucht hat und warum man diese Lösung sucht und keine andere.
 
Mich stört aber an dem Antwortstil (von 3 der 4 Antworten) dass überhaupt nicht auf die Frage eingegangen wird sondern versucht wird von etwas anderem zu überzeugen. Aber hier im Forum hat es sich scheinbar eingebürgert.

Keineswegs. Aber zumindest mir war aufgrund deiner Frage nicht klar, dass du dir diese Tools schon angeschaut hast. Wie gesagt, ich hatte mir zu dem Zeitpunkt deine anderen Threads noch nicht durchgelesen. Und meine hellseherischen Fähigkeiten lassen mit zunehmendem Alter auch immer mehr zu wünschen übrig. ;)

Aber back to topic; der Post von lisanet erklärt die Problematik meines Erachtens recht gut - nur zu wissen welche Versionen aktuell sind ist ja erst die halbe Miete. Da könntest du allenfalls wirklich auf Tools wie MacPorts aufbauen. Das muss nicht heissen, dass du alles damit machen musst, du kannst dir auf der Grundlage ja selbst was bauen. Aber damit hättest du zumindest schon mal Scripts und Tools, die ein ähnliches Problem bereits lösen.
 
Was ist kompilieren viel mehr als configure, make, make install?

in den meisten Fällen kommt man damit zum Ziel.
Aber was machst Du, wenn trotz aktueller und angeblich stabiler Sourcen ein Fehler beim kompilieren auftritt? Fehler suchen, Source anschauen, evtl. ist der Fehler ja selbst korrigierbar (Source korrigieren, evtl. andere Compiler-Flags, evtl. andere Versionen einer oder mehrerer Libraries, etc.), nach Lösung suchen (Foren durchstöbern, Entwickler / Maintainer anschreiben, etc.), evtl. Bug Report schreiben, und wenn Fehler von Dir korrigiert: Korrektur anfügen. Dann abwägen, ob man nicht doch lieber auf den/die Entwickler wartet (kommt ein Patch?). Unbeabsichtigte Folgen können sein, dass andere abhängige Software vielleicht rumzickt. Alles schon gehabt. Ich habe meine diesbezüglichen Erfahrungen unter Linux mit Samba, Cups und X in der Arbeit, sowie KDE und mplayer daheim machen dürfen. Blöd, wenn man immer die neuesten Features vorrätig haben soll. Das ist allerdings auch schon einige Jahre her, da musste man sich das Zeug noch einzeln per Hand runterladen bzw. erst mal nach der jeweils angeblich (!) richtigen Version stöbern. Hat rückwirkend nur bedingt Spaß gemacht.

Der Tipp MacPorts o. ä. zu benutzen macht wirklich Sinn. Dennoch ist man auch damit nicht immer vor Ärger gefeit.

Servus & viel Erfolg

kg
 
Aber was machst Du, wenn trotz aktueller und angeblich stabiler Sourcen ein Fehler beim kompilieren auftritt? Fehler suchen, Source anschauen, evtl. ist der Fehler ja selbst korrigierbar (Source korrigieren, evtl. andere Compiler-Flags, evtl. andere Versionen einer oder mehrerer Libraries, etc.), nach Lösung suchen (Foren durchstöbern, Entwickler / Maintainer anschreiben, etc.), evtl. Bug Report schreiben, und wenn Fehler von Dir korrigiert: Korrektur anfügen.
Hinter meiner Frage hat lediglich ein entsprechendes Smiley gefehlt, denn jeder der versucht im Terminal eigene Wege zu gehen bzw. Programme zu kompilieren, dürfte schon mehr als 95% der regulären Mac-User verstehen.

Ich habe Wochen gebraucht um mit Hilfe des sehr hilfreichen und freundlichen Entwicklers Moritz Bunkus den source code von mkvtoolnix so weit zu kriegen dass mkvtoolnix (inkl. GUI) mit aktuellem clang kompiliert. ffmpeg mit libass und aktuellem clang war auch nicht so einfach. Und auch in der Vergangenheit habe ich festgestellt dass die Entwickler auf freundliche und sachgerechte Fragen sehr bereitwillig geantwortet haben.

Und trotzdem hat die simple Frage ob jemand eine Möglichkeit kennt wie man auf verhältnismäßig einfache Weise überprüfen kann ob ein Source-Code aktualisiert wurde, einen Haufen an Belehrungen der Art "MacPorts blabala", "brew blabla", ... nach sich gezogen. Und das habe ich in auf macuser.de bei vielen Fragen sehr oft gesehen. Mir persönlich ist das ehrlich gesagt zu anstrengend (wobei ich definitiv nicht deinen Beitrag meine). Als sehr positive Beispiele (aka hilfsbereite User) würde ich z.B. gerne oneOeight oder Kaito erwähnen.
 
Wie und woher ziehst du denn deine sources?
Bei git gäbe es ja z.B. git status --untracked-files=no oder git diff ...
Damit könntest du zumindest github und sourceforge erschlagen.

macports halte ich in deinem Fall auch nicht für zielführend, weil die doch immer eine Weile hinterherhinken,
und so wie du dich anhörst, möchtest du ganz vorne dabei sein.
Um beim Beispiel git zu bleiben: macports git 2.0.1, aktuell ist aber 2.0.3.

Oder besser, um auf deine Linuxdistri einzugehen, könntest du z.B. Archlinux (RR) curlen (am Beispiel boost und git):
Code:
curl -s https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/[COLOR=#ff0000]boost[/COLOR] | grep -i 'pkgver='|cut -d'=' -f2
curl -s https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/[COLOR=#ff0000]git[/COLOR]   | grep -i 'pkgver='|cut -d'=' -f2

* Und damit baust du dir ein script, das deine Liste via for-loop abarbeitet.
 
Zuletzt bearbeitet:
Ich hab bislang ja absichtlich nichts gesagt, denn meiner Meinung nach ist die Antwort auf die Frage
Und trotzdem hat die simple Frage ob jemand eine Möglichkeit kennt wie man auf verhältnismäßig einfache Weise überprüfen kann ob ein Source-Code aktualisiert wurde
"gibts nicht", solange "einfach" in dem Satz vorkommt. ;)

Das Problem ist schlichtweg, dass die Quellen keinem einheitlichen Muster folgen, du musst also zur Prüfung für eine jede Quelle eine "individuelle" Lösung schreiben (und wenn es blos das greppen einer Versionsnummer von der Homepage der Quelle ist). Nicht nur das ist viel Arbeit, du musst auch ständig überprüfen ob deine Lösung noch funktioniert, oder z.B. die Homepage, von der du greppst, leicht verändert wurde.

Ein Paketmanager hat hier natürlich den Vorteil, dass diese Arbeit bereits von vielen anderen Leuten übernommen wird.
Eventuell ist es eine Lösung, sich eben doch eines Paketmanagers zu bedienen, aber halt nur so "halb". Im Falle von brew könntest du z.B. das Formularepo lokal via git aktuell halten und dir aus den nennenswerten Formeln die Download-URL greppen. In dieser befindet sich auch die Version der Software.
Das wäre dann nicht immer unbedingt absolut brand-aktuell, aber zumindest relativ aktuell und die ganze Arbeit wird weiterhin von den Maintainern gemacht. Zudem verändert sich die Struktur von z.B. einer brew Formel nicht von heute auf morgen so einfach, es ist also eine gewisse Konsistenz gegeben.

Auf jeden Fall ist viel handarbeit involviert, speziell beim aktuell halten. Daher würde ich versuchen diese Arbeit "auszulagern", indem du, wie genannt, auf die Repos eines Paketmanagers zugreifst, oder Mailinglisten abklapperst, wie ebenfalls erwähnt wurde.
 
Zurück
Oben Unten