Vorbilder und Vorschläge für eine Paketaufteilung für OpenWrt?

[maf]

Hallo,

um die Installation von FHEM auf einem Router mit OpenWrt zu erleichtern, arbeite ich an einer Paketierung von FHEM. OpenWrt benutzt eine eigene Paketverwaltung (vergleichbar mit APT in Debian). Vorteile der Bereitstellung von Paketen in einem Repository wären die automatische Installation von Voraussetzungen (Perl und FHEM-interne Abhängigkeiten), eine einheitliche Installationsstruktur und die Möglichkeit zur kontrollierten Deinstallation (und damit auch eine niedrigere Hemmschwelle bei Testinstallationen).

Eine erster monolithisches Paket habe ich erstellt. Es enthält fhem.pl, fhem.cfg sowie die Dateien in FHEM, contrib und www. Mit knapp 6 MB ist es allerdings zu groß für die meisten Router. Ich würde FHEM deshalb gerne in mehrere kleinere Pakete aufteilen. Der Benutzer muss dann nur noch diejenigen Pakete installieren, die er für seine Hardware und seine Aufgabenstellung benötigt.

Vermutlich sollte es Pakete geben wie fhem-base, fhem-www und fhem-cul, dazu Pakete für die unterschiedlichen Hausautomations-Systeme und viele andere Pakete. Aber leide kenne ich mich mit den meisten Komponenten noch überhaupt nicht aus. Deshalb suche ich Vorbilder und Vorschläge für eine sinnvolle Aufteilung des Gesamtpakets, idealerweise mit Hinweisen zu den jeweiligen Voraussetzungen und Abhängigkeiten zwischen den Paketen.

Gruß
maf

[betateilchen]

Lohnt sich der Aufwand wirklich? Vermutlich wirst Du auf einem OpenWRT Router in den allermeisten Fällen ohnehin nicht alle perl-Module installiert bekommen, die man als Voraussetzung braucht, um ein etwas komplexeres fhem laufen zu lassen.

[maf]

Ich habe zwei Beschreibungen für die Installation von FHEM und seinen Voraussetzungen unter OpenWrt gefunden: Im  FHEM Wiki und im OpenWrt Wiki. In beiden wird zunächst einmal "alles" installiert: Viele Perl-Module und das gesamte FHEM. Selbst das scheint also zu gehen. Und mit einem USB Stick kann man den Speicherplatz für Programme notfalls leicht erweitern.

Eines meiner Ziel ist es jedoch gerade, kleinere Installationen zu ermöglichen. Falls man für FHEM immer "alle" Perl-Module benötigt, lässt sich natürlich wenig Platz einsparen. Doch ich hoffe, dass es nicht ganz so schlimm ist. Zumindest bei FHEM selbst sollte sich aber einiger Platz sparen lassen, wenn man nur installieren muss, was man für seine Hardware und seine Automatisierungswünsche benötigt.

Der Aufwand für die Paketerstellung ist zum Glück bei OpenWrt relativ gering. Der Aufwand dafür, die Abhängigkeiten innerhalb von FHEM sowie zwischen FHEM und Perl sauber zu identifizieren, ist deutlich höher. Meine Hoffnung ist natürlich, dass es schon irgendwo Informationen darüber gibt. Falls nicht, würde ich versuchen, ob mir Programme zur Ermittlung und Visualisierung von Abhängigkeiten zwischen Perl-Modulen weiterhelfen.

Weil ich FHEM selbst noch nicht einsetze, kann ich nicht beurteilen, welche Komponenten immer, oft oder selten benötigt werden. Vielleicht gibt es ja auch typische Einsatzfälle, zu denen immer die gleichen Modulkombinationen benötigt werden? Gerade da setze ich auf Eure Erfahrungen und Ratschläge.

Ich habe jedenfalls immer wieder die Erfahrung gemacht, dass sich der Aufwand für die Paketerstellung - ob nun bei OpenWrt oder bei Debian/Ubuntu - gelohnt hat. Selbst wenn sich kaum Platz sparen lassen sollte: Eine reproduzierbare Installation und eine zuverlässige Deinstallation sind mir schon einiges wert. Außerdem lerne ich bei der Paketerstellung oft etwas, dass mir später Konfiguration und Einsatz hilft.

[rudolfkoenig]

Das contrib Verzeichnis kann man sparen.
Der Rest ist schwierig, weil man (d.h. Module/Entwickler und Supporter hier im Forum) davon ausgeht, das alles da ist.

[maf]

Wäre denn innerhalb von FHEM eine Unterschweidung zwischen Basismodulen (d.h. unverzichtbar), hardwarespezifischen Modulen (z.B. für CUL oder andere Transceiver) und automatisierungssystemspezifischen Modulen (z.B. FS20, HomeMatic) möglich?

[rudolfkoenig]

Kurz: Moeglich ist vieles, allerdings werde ich keinen Aufwand treiben, so kleine Systeme zu unterstuetzen, da ich die Nerven der Entwickler und Anwender schonen will.

Lang: FHEM ohne perl belegt ca 20MB, mit Perl (je nach Modulen) ca 50. Ein mittleres FHEM-System generiert ca 50MB logs pro Jahr, fuer backup/restore fallen auch schnell 20MB an. Ein 4gb USB-Stick (gibts noch sowas kleines?) kostet unter 10 Euro, ich werde keine Energie reinstecken, um irgendwo 5 MB sparen zu koennen, das finde ich naemlich sinnlos.

[maf]

Das leuchtet mir ein. Mir war nicht klar, dass FHEM selbst nur den kleineren Teil des insgesamt benötigten Speicherplatzes in Anspruch nimmt. Dann hat es wenig Sinn, durch Aufspaltung von FHEM ein paar MB einzusparen.

Ich sollte also vor allem versuchen sicherzustellen, dass bei der Installation die Abhängigkeiten erfüllt werden. Vielleicht gibt es auch eine Möglichkeit, bei Installationsbeginn zu überprüfen, ob der Speicherplatz überhaupt reicht, und eine Installation unter Verwendung eines externen Speichermediums anzubieten. Und dann kann ich vielleicht immer noch, wie von Dir vorgeschlagen, contrib zu einem eigenen Paket machen.

Außerdem habe ich den Verdacht, dass ich mich mit dem FHEM-eigenen Update-Mechanismus beschäftigen muss. Bei "normalen" Paket würde ja die Aktualisierung ausschließlich über die Installation einer neuen Paketversion erfolgen. Bei FHEM ist das offensichtlich anders. Im Zuge eines Updates könnten vermutlich auch neue Dateien installiert werden (und nicht nur neue Versionen bereits existiertender Dateien)? Und was würde beim Update passieren, wenn ein ganzes Verzeichnis (wie z.B. contrib) nicht existierte?

[hexenmeister]

wenn ein ganzes Verzeichnis (wie z.B. contrib) nicht existierte?

Contrib wird, soweit ich weiß, gar nicht upgadated. Auch ein Extra-Contrib-Paket macht IMHO keinen Sinn. Wenn man etwas davon benötigt, kann man auch direkt aus SVN nehmen. Für so kleine Systeme ist das definitiv die bessere Option.

[maf]

Ok. Allerdings sind es vielleicht gerade diejenigen FHEM Nutzer, die mit SVN nicht so viel anfangen können, die eine Paketinstallation einfacher fänden. Mein Aufwand für ein separates contrib-Paket ist wirklich minimal. Und der Anwender hätte die Wahl zwischen der (einfachen) Installation des gesamten contrib und der (platzsparenden) Installation einzelner Komponenten direkt aus SVN.

Können denn im Verzeichnis FHEM durch ein Update neue Dateien dazukommen? Kann ich mir die Funktion von Update generell so vorstellen, dass es eine lokale Installation auf den Stand des SVN Repository bringt?

[hexenmeister]

Contrib muss man sich nicht als eine 'Installation', sondern eher als ein Ablageplatz vorstellen. Wenn man ein Modul oder sonst was daraus haben will, muss man das je per Hand an die richtige Stelle kopieren.

Per Update können Dateien dazu kommen. Die Installation wird auf SVN Stand gebracht. Bis auf paar Ausnahmen wie Contrib.

[maf]

Jetzt verstehe ich. Dann ergibt ein contrib-Paket für kleine Zielsysteme keinen Sinn.

OpenWrt Pakete können ihre Dateien auch aus SVN-Repositories ziehen. Eventuell könnte ein Update von FHEM also auch über einen Update des Pakets erfolgen. Das würde aber nur zuverlässig funktionieren, wenn das FHEM-eigene Update keine komplizierten Einzelregeln enthält. Dafür kann ich mir dann (später) immer noch das Update-Modul anschauen. Wenn beim Update keine Dateien außerhalb der schon bei der Erstinstallation angelegten Verzeichnisse erstellt werden, lässt sich eine vollständige Deinstallation sicherstellen.

[hexenmeister]

Update ändert Dateien, soweit mir bekannt ist, nur in dem Hauptverzeichnis und dadrunter. Da können aber auch neue angelegt werden.

[betateilchen]

Update ändert Dateien, soweit mir bekannt ist, nur in dem Hauptverzeichnis und dadrunter. Da können aber auch neue angelegt werden.

Da kannst Du anlegen was Du willst, update wird es schlichtweg ignorieren, solange Rudi den update-Prozess dafür nicht anpasst. Und Rudi verteilt gerne mal virtuelle Haue, wenn man einfach irgendwo ein neues Unterverzeichnis eincheckt und er dazu nicht seine Zustimmung gegeben hat.

[hexenmeister]

@betateilchen
Ich habe mich etwas unglücklich ausgedrückt. Ich habe schon gemeint, dass die neuen Dateien und Verzeichnisse von dem Update-Prozess angelegt werden können.

[maf]

So habe ich es auch verstanden.

In Hinblick auf die Paketerstellung war's mir nur wichtig zu wissen, ob beim FHEM-eigenen Update neue Verzeichnisse oder Dateien außerhalb des existierenden Stammverzeichnisses angelegt werden können. Die wären ein Stolperstein bei einer sauberen Deinstallation und würden eine neue Paketversion erforderlich machen.

Letztlich werden bei der Installation des Pakets auch nur alle Dateien an die "üblichen" Stellen kopiert. Ich würde es doch nicht wagen, den Zorn der Entwickler oder der Benutzer auf mich zu ziehen, indem ich bei der Paketerstellung die Projektstruktur verbiege .