Updates von Programmen die nicht aus dem Repository kommen

[mcdaniels]

Hallo und guten Morgen,
mich würde interessieren, wie ihr es mit Programmen hält, die nicht per apt-get installiert werden und folglich also nicht per apt-get upgrade aktuell gehalten werden können.

Am Beispiel von roundcube, welches nicht mehr in den Repos von "Jessie" zu finden ist, wird der Tarball heruntergeladen und in eine Verzeichnis enpackt / installiert / konfiguriert.

Nun läuft der Server dahin, man macht zwar brav die apt-gets' Roundcube jedoch, wird älter und älter.

Will heißen, hier MUSS man manuell aktualisieren.

Gibt es hier eine bessere Lösung, oder ist das einfach so?

PS: Da fällt mir ein, es gäbe da noch die Backports...

Danke!

[hikaru]

PS: Da fällt mir ein, es gäbe da noch die Backports...

Erstens das, und zweitens würde ich eher versuchen, mir selbst Backports aus Testing- oder Unstable-Paketen zu bauen, bevor ich irgendwo Tarballs hinkippe. Das macht zumindest das Putzen einfacher.

[mcdaniels]

andererseits hast du bei den Backports aber keine Securityupdates.

Selbst bauen: Hab ich noch nie gemacht.

[pferdefreund]

Ich habe z. B Postgresql immer in der aktuellen Version. Das baue ich aus den sourcen und schaue manuell halt regelmäßig nach, ob es updates gibt. Selbstgeschriebene Programme werden entweder per checkinstall ins System integriert - oder wenn länge dran gebastelt wird, in einen eigenen Ordner unter /usr/local gepackt. so ala /usr/local/meins mit den Unterordnern bin, lib, etc var und was man so braucht.
Dann ist die Deinstallation mit einem rm -r /usr/local/meins problemlos möglich und wenn ich durch Zufall einen bestehenden Namen für ein Programm usw verwendet haben sollte, tut es nicht weh - liegt ja ausserhalb der üblichen Kandidaten. Man muss natürlich bei solchen Aktionen dann für die Anwender, die es nutzen $PATH und LD_LIBRARY_PATH entsprechend setzen.

[KBDCALLS]

Es gibt ja in den Backports roundcube 1.1.5 Dar Paketbau ist eigentlich kein Hexenwerk , wenn man die Debiansourcen dazu nutzt. Baut man mit pbuilder die 1.2.2 von Testing/unstable dann bekommt von lintian einige Errors um die Ohren gehauen.

Code: Alles auswählen

E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/cleandb.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/decrypt.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/deluser.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/dumpschema.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/gc.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/indexcontacts.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/initdb.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/installto.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/moduserprefs.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/msgexport.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/msgimport.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/update.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/updatecss.sh
E: roundcube-core: php-script-but-no-phpX-cli-dep usr/share/roundcube/bin/updatedb.sh

[mcdaniels]

Hallo,
danke für die Rückmeldungen!

[debianoli]

Schau mal hier: https://wiki.debian.org/HowToPackageForDebian

[hikaru]

Wenn es um Paketselbstbau geht, dann finde ich das Tutorial von Lucas Nussbaum [1] bisher am verständlichsten. Jedenfalls hatte ich da bisher das einzige mal den Eindruck einer einigermaßen lückenlosen Dokumentation der Zusammenhänge, wenn auch vielleicht auf Kosten der Tiefe bei einzelnen Punkten. Alles andere erschien mir eher wie ein Spickzettel für Leute, die eigentlich wissen wie es geht, oder es behandelte nur Ausschnitte des Paketbaus, wie z.B. das Erstellen eigener Backports aus bereits debianisierten Quellen.
Die Feuerprobe, ein Paket von scratch nur aus Upstream-Quellen zu bauen, habe ich aber auch noch vor mir.

[1] https://www.debian.org/doc/manuals/pack ... ial.en.pdf

[Methos]

Wie aktuell sind eigentlich die

Code: Alles auswählen

deb http://ftp.us.debian.org/debian jessie-backports main

Auf einem Server ist nämlich immer noch die Version

Code: Alles auswählen

roundcube                         1.1.5+dfsg.1-1~bpo8+1

installiert und es gibt kein Update auf 1.1.7 welche ja die Sicherheitslücke schließen sollte.
Hab es bereits manuell geschlossen, aber so ganz sicher fühle ich mich trotzdem nicht

[rendegast]

Du könntest roundcubemail-1.1.7 (nicht -framework, nicht -complete)
mit den dsc und debian.tar.gz des 1.1.5-jessie-backports als Paket(e) bauen.

Auf die Schnelle ist mir nur aufgefallen,
daß von den für 1.1.5.deb verwendeten Patches (debian/patches/series) der Patch
debian/patches/Fix-vulnerability-in-handling-of-mail-s-5th-argument
in 1.1.7 schon eingebaut ist.
(Mehrfachanwendung würde aber wohl nur unschädliche backup-Kopien erzeugen)

Eher interessant wäre zu wissen, ob und wie
debian/sql/
für 1.1.5 -> 1.1.7 ergänzt werden müßte.

debian/missing-sources/
braucht Upgrades?