[Trunk] vnstat (& Makefile-"SUBOPTS")

[er13]

@chaosjack: sollte in 4053 gefixt sein, bitte testen

@cuma: das waren jetzt aber a bissl zu viele Fehler, bitte aufpassen

 

[cuma]

Sorry, bei mir lief es ja durch

 

[chaosjack]

@er13
der Trunk ist ja mittleiweile bei der 4060 und damit läuft es durch
vielen Dank für das superschnelle Fixen

 

[er13]

Soweit ich das verstanden hatte, bleibt (momentaner Stand) das komplette Verzeichnis packages/<welchespaket auch immer> genauso bestehen, wie es ist; nur die veränderten Binaries werden über ein vorhandenes kopiert und (das ist hier das Problem) die für die neue Auswahl nicht mehr benötigten Dateien (die "unnötigen" Binaries) bleiben ebenfalls vorhanden.

das Problem genau erfasst

Alle Änderungen, die ich an CGI, default-Werten usw. in dem Ordner gemacht habe, sind nach dem Make-Lauf noch immer vorhanden.

Änderungen an Dateien im packages-Ordner vorzunehmen macht für mich keinen Sinn (es ist quasi ein Temp-Ordner, nach einem $(packagename)-dirclean ist er weg), alle Änderungen sollen in dem make/$(packagename)-Ordner gemacht werden, dann können sie auch leichter in upstream submittet werden

Aber vielleicht warten wir mal, ob sonst noch wer eine Meinung zu dem Thema hat...

Nachdem sich keiner zum Thema äußert, erzwinge ich es mal mit Gewalt meine Lösung in 4073 eingecheckt, mal schauen, ob es irgendwelche Nebeneffekte gibt, bei mir bisher keine

 

[olistudent]

Wie bereits geschrieben hatten wir das so ähnlich schonmal drin. Nur damals war der Effekt, dass die Package Dateien nach dem Kopieren gelöscht wurden und so nur die Binaries ins Image kamen. Weil ich den Fehler nicht fixen konnte und mir keiner helfen wollte/konnte hab ich den rm-Befehl, dann wieder entfernt.

Mfg Oliver

Edit: http://trac.freetz.org/changeset/3280/trunk/make/Makefile.in
Nach dem Kommentar wars nichtmal Absicht. ;-)

 

[er13]

@oliver: Nachdem es schon mal so oder so ähnlich war (bin übrigens auf die Lösung gekommen, ohne es zu wissen), heißt es, dass Du nichts dagegen hättest, vorausgesetzt es gibt keine Nebeneffekte?

Nur damals war der Effekt, dass die Package Dateien nach dem Kopieren gelöscht wurden und so nur die Binaries ins Image kamen.

der Fix dafür ist denbkar einfach Zeile 450

 

[MaxMuster]

Änderungen an Dateien im packages-Ordner vorzunehmen macht für mich keinen Sinn

.. Tja, das ist halt gerade meine bisherige Vorgehensweise (speziell für Änderungen am CGI) gewesen:
- kleine Dinge erstmal direkt im "übergemounteten" CGI auf der Box testen (ohne die zwei Sprachen)
- dann das im packages-Ordner umsetzen (mit den Sprachen)
- zuletzt dann in den make-Ordner aufnehmen zum "Fixieren"

Wie gesagt, mich "stört", ist, dass der Sonderfall für ein (oder ein paar) Pakete jetzt alle Pakete beeinflusst und jetzt alle Pakete komplett gelöscht werden, bei denen sich was ändert, obwohl das absolut unnötig ist. Die Tatsache, dass es vielleicht bei den meisten "nicht stört" ändert ja nichts daran, dass es überflüssig ist ;-)

Jörg

 

[er13]

- kleine Dinge erstmal direkt im "übergemounteten" CGI auf der Box testen (ohne die zwei Sprachen)
- dann das im packages-Ordner umsetzen (mit den Sprachen)
- zuletzt dann in den make-Ordner aufnehmen zum "Fixieren"

Da kann ich ehrlich gesagt Dir nicht ganz folgen... Was ist der Sinn vom Schritt 2? Die cgi/config/init-Dateien in beiden Verzeichnissen sind absolut identisch, d.h. Schirtt 3, dieses Fixieren, besteht lediglich in dem Kopieren der Dateien aus dem packages-Ordner in den make-Ordner. Zweisprachig könntest Du die Dateien doch gleich in dem make-Ordner machen. Und dann gehen Deine Änderungen bei einem unbeabsichtigten dirclean auch nicht verloren.

Ich denke, dass Dein Prozess an der Stelle etwas suboptimal ist, und es eher dieser an freetz angepasst werden sollte als umgekehrt (zu Not kannst Du ja das Changeset immer in Deinem lokalen Baum reverten). Nimm' es bitte nicht als Arroganz auf, bloß bisher hast Du mich nicht überzeugen können, dass dieses Löschen überflüssig ist. Es ist deutlich einfacher das komplette Verzeichnis zu löschen als in jedem Paket einzelne Regeln zu implementieren die explizit, die nicht benötigten Binaries löschen. Es ist schließlich unser Freizeitprojekt...

 

[MaxMuster]

Da kann ich ehrlich gesagt Dir nicht ganz folgen... Was ist der Sinn vom Schritt 2?

Ich will einen einfachen Weg dafür haben, denn dieser Prozess ist an das vorhandene Freetz (was "nicht sinnlos rumlöscht ;-);-)") angepasst:
- CGI editieren, make, fertig.

Das Ändern im make/... Unterordner wäre im einfachsten Fall:
- CGI editieren; rm packages/<paket> ; rm packages/.<paket>; make

und offen gesagt stört mich daran das gleiche, wie bei deinem jetzigen Vorgehen: Ich weiß ganz genau, was zu ändern ist, aber statt das zu tun, schmeiße ich alles weg um die Änderung von woanders zu übernehmen...

Es ist deutlich einfacher das komplette Verzeichnis zu löschen als in jedem Paket einzelne Regeln zu implementieren die explizit, die nicht benötigten Binaries löschen. Es ist schließlich unser Freizeitprojekt...

Und mir geht es mit deinem Ansatz so, dass ich ihn nicht verstehe ;-):

Es gibt ein einziges neues Paket, bei dem eventuell eine Datei, die bekannt ist, gelöscht werden soll. Jetzt sagst du "ich mag kein explizites Löschen" (so habe ich das verstanden), also lösche ich einfach alle pakete, bei denen sich überhaupt etwas ändert, denn damit kann ich zufällig auch das explizite Löschen bei meinem einen Paket vermeiden.

Im Makefile werden immer Dateien explizit irgendwohin kopiert und die evt. zu löschenden Dateien sind bekannt (das "Problem" betrifft ja eben nur eine winzigen Teil der Pakete). Warum "magst" du den Ansatz nicht, nur das zu tun, was nötig ist, und einfach diese Datei dort zu löschen??

Die ernsthafte Umsetzung deines Ansatzes wäre, am Begin jedes make Laufes ein "rm -rf packages/*" einzuführen. Damit könnte man sich zudem noch den ganzen Aufwand mit den .-Files sparen ;-) Dann wäre es wenigstens durchgängig so, dass immer alle Pakete gelöscht werden und auch in allen Paketen die files-Subornder neu angeleget würden. Dann könnte ich übrigens auch meine Änderungen und Tests im make-Ordner machen, weil ein einfaches make die Dinge ja rüberkopiert...

Wie gesagt, mir fehlt das echte Argument für eine solche Änderung, die aus meiner Sicht nur ein Bespiel für "Kanonen auf Spatzen" ist.


Jörg

 

[Silent-Tears]

Aber alles löschen funktioniert immerhin Und so lang man nicht in ./sources/ löscht, sondern "nur" in ./packages/ wird nicht komplett neu gebaut, sondern nur neu zurechtkopiert.

Ich selber war schon vor einigen Monaten für eine interne Versionierung unserer Pakete, vorrangig allerdings der CGIs, da diese nicht immer neu kopiert/gebaut werden bei Versionsänderungen....

 

[er13]

Und mir geht es mit deinem Ansatz so, dass ich ihn nicht verstehe ;-)

Also nochmal, mir geht es darum, den von cuma gefundenen Bug zu beheben und zwar mit möglichst wenig Aufwand und wenn es geht generisch. Ich habe nur dann etwas gegen explizites löschen, wenn es in jedem Multibinary-Paket aufs neue implementiert werden muss.

cuma hat das Problem mit vnstat entdeckt, ich behaupte das gleiche Problem besteht mit dem subversion-Paket (7 Binaries), mit dem e2fsprogs-Paket(16 Binaries wenn ich mich nicht verzählt habe), vielleicht mit noch ein paar anderen. In einem anderen Thread habe ich einen ersten Versuch gestartet, asterisk Paket für freetz zu erstellen, da gibt es 164 Module. Da möchte ich mal sehen, wie kurz Du das Makefile mit expliziten Löschregeln für alle möglichen Konstellationen halten kannst.

Außerdem wären diese Löschregeln alles Code-Clones, für mich sind schon zwei INSTALL_BINARY_STRIPs in einem und demselben Makefile ein Code-Clone. Stichwort Wartung: da gehen in manchen IT-Projekten bis zu 80% aller Kosten drauf. Ich möchte, dass es zu der Wartung der Regeln gar nicht kommt, weil sie erst gar nicht entstehen. Makefiles sollten kurz und verständlich sein und nur das wirklich notwendige machen. Dies würde auch den Einstieg einem Newbie erleichtern.

also lösche ich einfach alle pakete, bei denen sich überhaupt etwas ändert, denn damit kann ich zufällig auch das explizite Löschen bei meinem einen Paket vermeiden.

damit bei den anderen, die mitlesen, kein falscher Eindruck entsteht. Es wird nur dann etwas gelöscht, wenn man im Menuconfig bei einem Paket eine Option verstellt (wie oft passiert denn das bitte) und diese dazu als SUBOPT im Makefile vom Paket definiert ist. Und es wird wirklich nur das betroffene Paket gelöscht nicht alle.

Für Dich, Jörg, heißt es, dass wenn Du im menuconfig keine der Subopts verstellst, dann ändert sich für Dich rein gar nichts, Du kannst weiterhin cgis im packages-Verzeichnis editieren, es wird nichts gelöscht.

p.s. Und wenn Dir die Lösung einfällt (am besten gleich als Patch ), die eben die Eigenschaft hat generisch zu sein und wenig Aufwand in jedem Multibinary-Paket nach sich zieht, dann nur zu, dann fliegt meine Lösung sofort wieder raus.

 

[cuma]

Das Prolem ist schon ziehmlich alt, nämlich so alt wie Samba für Freetz. Bislang waren aber aller mit dem zusätzlichen clean-Traget zufrieden

 

[olistudent]

Bei Samba mag das ja noch okay sein. Aber für e2fsprogs ist das schon sehr unschön.

MfG Oliver

 

[MaxMuster]

p.s. Und wenn Dir die Lösung einfällt (am besten gleich als Patch ), die eben die Eigenschaft hat generisch zu sein und wenig Aufwand in jedem Multibinary-Paket nach sich zieht, dann nur zu, dann fliegt meine Lösung sofort wieder raus.

Na gut, wenn man nicht alles selbst macht ;-)

Ich schlage also nochmal vor, die Binaries, die nicht benötigt werden, einfach zu löschen. Für das vnstat.mk ginge das so (nur kurz getestet, aber die Idee sollte klar sein):

Index: make/vnstat/vnstat.mk
===================================================================
--- make/vnstat/vnstat.mk	(Revision 4076)
+++ make/vnstat/vnstat.mk	(Arbeitskopie)
@@ -4,6 +4,7 @@
 $(PKG)_SITE:=http://humdi.net/vnstat
 $(PKG)_BINARIES_ALL := vnstat vnstatd vnstati
 $(PKG)_BINARIES := $(filter-out $(if $(FREETZ_PACKAGE_VNSTAT_DAEMON),,vnstatd) $(if $(FREETZ_PACKAGE_VNSTAT_IMAGE),,vnstati),$($(PKG)_BINARIES_ALL))
+$(PKG)_BINARIES_UNUSED := $(filter-out $($(PKG)_BINARIES) ,$($(PKG)_BINARIES_ALL))
 $(PKG)_BINARIES_BUILD_DIR := $($(PKG)_BINARIES:%=$($(PKG)_DIR)/src/%)
 $(PKG)_BINARIES_TARGET_DIR := $($(PKG)_BINARIES:%=$($(PKG)_DEST_DIR)/usr/bin/%)
 
@@ -29,6 +30,7 @@
 	$(INSTALL_BINARY_STRIP)
 
 $(pkg):
+	@$(RM) $(VNSTAT_BINARIES_UNUSED:%=$(VNSTAT_DEST_DIR)/usr/bin/%)
 
 $(pkg)-precompiled: $($(PKG)_BINARIES_TARGET_DIR)

Jörg

 

[er13]

@Jörg: an genau das gleiche habe ich auch schon gedacht , bloß wollte ich die Löschzeile in make/Makefile.in unterbringen, sodass man im Paket nur eine Variable zu definieren braucht

 

[MaxMuster]

... darf natürlich gerne noch "gehübscht" oder optimiert werden, ich wollte ja nur "beweisen", dass das mit wenigen Zeilen Code möglich wäre

Jörg

 

[cuma]

Ist es dann aber nicht so, dass überflüssige gelöscht werden und danach kopiert wird?. Inclusiver der noch vorhandenen nicht gewollten?

 

[MaxMuster]

... hm, also der Patch oben erzeugt aus der Liste aller und der gewünschten eine Liste der "nicht gewählten" Binaries und löscht diese aus dem packages/vnstat... Unterordner. Damit ist sichergestellt, dass "höchstens" die drin sind, die du gewählt hast. Es könnte lediglich der Versuch auftreten, ein "unerwünschtes" Binary zu Löschen, was im Ordner gar nicht ist, das ist aber wohl zu verschmerzen ;-).
Danach wird das Vorhandensein der "gewünschten" Binaries überprüft und diese werden, sofern noch nicht übersetzt erstmal übersetzt und dann aus dem source-Ordner in das packages Verzeichnis kopiert. Ist umgangssprachlich manchmal etwas schwer zu beschreiben, aber ich hoffe, es wird klar.

Jörg

 

[er13]

@cuma: zwar immer noch nicht getestet, aber vom Lesen her, ist alles korrekt. Die Mengen der zu installierenden und der zu löschenden Binaries sind disjunkt, denn das zweite vom Jörg hinzugefügte filter-out rechnet das Komplement zu der zu installierenden Menge.

 

[er13]

@Mod: zwei Beiträge hintereinander damit man mitkriegt, dass sich etwas getan hat

@alle anderen: die Lösung von Jörg etwas generischer anbei, theoretisch könnte ich mir mit dieser noch ein Problem vorstellen, das checke ich aber morgen bzw. schon heute und berichte dann