OpenSLX

dnbd(2)-client

Befinden sich auf im svn unter /contrib/dnbd(2)

libhal*/*libdbus*/*nbd-client*

libhal* und libdbus brauchen wir eigentlich nicht mehr, da sie nicht mehr von der modifizierten hwinfo Version benötigt werden.

Alle drei sich mit einer leicht modifizierten gentoo-uclibc Buildumgebung direkt per emerge bauen. Problem hierbei ist allerdings: die Pakete ziehen einige Abhängigkeiten mit sich die sich nicht mit der uclibc vertragen - hauptsächlich handelt es sich hierbei um glib2/iconv. Siehe hierzu auch den Abschnitt Anpassungen für OpenSLX auf GentooUclibcChroot.

Lösung momentan zwei gentoo-uclibc Umgebungen - eine "saubere" Instanz und eine mit glib2/iconv in der nur die betroffenen Pakte gebaut werden.

hwinfo

Es existiert eine gepatchte Version (die die Abhängigkeit von libhal/libdbus beseitigt) - pack ich nachher ins SVN.

Der nbd-client hat keine Anpassungen, der dnbd-client ist unter contrib/dnbd/trunk/client (nicht weiter angepasst) zu finden.

Die modifizierten hwinfo Versionen sind jetzt unter /openslx-src-tools/hwinfo zu finden. Die aktuelle (15.x) im trunk, die älteren Versionen unter branches.

Der nbd-client selbst braucht keine glib2 - nur der nbd-server. Leider steht in Gentoo nur ein Paket für Client und Server zur Verfügung, daher die Abhängigkeiten. Vermutlich wäre es das Beste den nbd-client auch im SVN unter /openslx-src-tools/ zu verwalten.

Replying to [comment:4 schmelzs]:

Die modifizierten hwinfo Versionen sind jetzt unter /openslx-src-tools/hwinfo zu finden.
Die aktuelle (15.x) im trunk, die älteren Versionen unter branches.

Hm, schon, aber man kann jetzt keinerlei Patches mehr erkennen, weil Du Deine veränderten Sourcen als Block eingecheckt hast. So kann ich z. B. nicht herausfinden, was Du gegenüber dem Original verändert hast.
Das übliche Vorgehen bei 3rd-Party-Sourcen ist das Einchecken des Originals (der kopierten, unveränderen Sourcen) als Vendor-Branch (in unserem Fall heißt dass in das 'vendor' Repo) und dann das Kopieren des Vendor-Branches in das eigentliche hwinfo-Verzeichnis im openslx-src-tools Repo (dort in den trunk).

Eine genau Beschreibung des Vorgangs und der Gedanken dahinter findest Du im subversion-Buch:
http://svnbook.red-bean.com/nightly/de/svn.advanced.vendorbr.html

Dort muss ich das selbst immer wieder nachlesen ;-)

Ich bin für die busybox diesem Vorgehensmodell gefolgt, so dass es natürlich am besten wäre, das für alle anderen Tools auch so zu machen.
Da es ja drei Versionen von hwinfo gibt, empfiehlt es sich wohl, mit der ältesten Version anzufangen, diese anschließend zu taggen und dann die nächste Version aus dem eigenen vendor-Branch über den trunk der alten Version zu mergen (d.h. die Änderungen der zwei Versionen auf den trunk zu übertragen und dann die eventuellen Konflikte aufzulösen).

Replying to [comment:5 schmelzs]:

Der nbd-client selbst braucht keine glib2 - nur der nbd-server.
Leider steht in Gentoo nur ein Paket für Client und Server zur Verfügung, daher die
Abhängigkeiten. Vermutlich wäre es das Beste den nbd-client
auch im SVN unter /openslx-src-tools/ zu verwalten.

Na, wenn wir keine Änderungen vorgenommen habe, brauchen wir auch keine eigene Kopie vorhalten, denke ich. IIRC hast Du doch einen Weg gefunden, die Abhängigkeit auf glib2 zum Funktionieren zu überreden, oder? Dann könnte man doch einfach in der Buildumgebung den nbd per emerge einspielen und dann nur den nbd-client in das uclib-rootfs kopieren.
Ich nehme mal an, genau so hast Du es doch schon gemacht, oder nicht?

Replying to [comment:7 zooey]:

Replying to [comment:5 schmelzs]:

Der nbd-client selbst braucht keine glib2 - nur der nbd-server.
Leider steht in Gentoo nur ein Paket für Client und Server zur Verfügung, daher die
Abhängigkeiten. Vermutlich wäre es das Beste den nbd-client
auch im SVN unter /openslx-src-tools/ zu verwalten.

Na, wenn wir keine Änderungen vorgenommen habe, brauchen wir auch keine eigene Kopie vorhalten, denke ich. IIRC hast Du doch einen Weg gefunden, die Abhängigkeit auf glib2 zum Funktionieren zu überreden, oder? Dann könnte man doch einfach in der Buildumgebung den nbd per emerge einspielen und dann nur den nbd-client in das uclib-rootfs kopieren.
Ich nehme mal an, genau so hast Du es doch schon gemacht, oder nicht?

Jain. Problem ist in Gentoo gibts ndb-client nur in Kombination mit dem nbd-server, welcher wiederum glib2 braucht - sprich man braucht um emerge zu nutzen die modifizierte Buildumgebung. Und von dieser möchte ich eigentlich weg, weil es meiner Ansicht nach keinen Sinn macht zwei Buildumgebungen zu pflegen (nur wegen 1-2 Paketen).

Ich habe jetzt den nbd-client Code aus dem Bundle genommen, mit nem eigenen Makefile versehen und bei den openslx-src-tools abgelegt.