Vorschlag für neuen Patch: --with-features=...

[rhabarber1848]

Hi,

eine neue Idee für einen Patch ist mir heute durch den Kopf gegangen.

Wenn jemand in einem Flashimage die Tools ps und/oder top nicht in der
Busybox-Version, sondern in der procps-Version haben möchte, müssen
einige Klimmzüge gemacht werden, um das Ziel zu erreichen. Dennoch
ist in einem solchen Image der Code für ps und top weiterhin in Busybox
enthalten und verschwendet Platz. In yadd-none ist procps bereits fester
Bestandteil, obwohl ps/top auch in Busybox aktiv sind...

cdk/Patches/busybox.config.m4

Code: Alles auswählen

option(`CONFIG_PS', `y', `y')
option(`CONFIG_TOP', `y', `y')

Es gibt weitere Tools, wo es Sinn machen kann, auf die Busybox-Version
zu verzichten, Busybox-hdparm beispielsweise unterstützt den Parameter
-M für das Akkustikmanagement nicht.

Mein Vorschlag ist die Einführung einer neuen ./configure-Option

--with-standaloneversions=ps,top,hdparm,...

Tools, die hier aufgeführt sind, werden aus dem Original-Sourcecode
heraus kompiliert und das Busybox-Pendant deaktiviert.

Meine Frage nun an Euch, macht ein solcher Patch Sinn?
Wenn ja, hätte ich gerne Vorschläge für weitere Programme, die in
dieser Option berücksichtigt werden sollten.

[rhabarber1848]

PS: --with-tools=dboxshot,fbshot wäre natürlich auch möglich.
Es geht nicht nur darum, Features der Busybox zu ersetzen.

[GetAway]

fsck ist auch so ein Kandidat. Er wird mit e2fsprogs gebaut und in Busybox.

[seife]

Ich finde das nicht soo dringend. Die busybox-config passt man sich ja eh an, und für alles andere gibt es ja schon flash-targets, so dass man einfach vor dem "zusammenpacken" noch mal "make flash-dboxshot; make flash-procps; make flash-foobar" macht. (OK, "make flash-procps" müsste mal jemand machen, das gibt es noch nicht).

Versteh das nicht falsch: ich bin nicht prinzipiell gegen Erweiterung der configure-Optionen, allerdings wird es irgendwann genauso kompliziert, die richtigen Optionen zusammenzustellen wie jetzt, die passenden flashtargets aufzurufen.

Ausserdem wird das gern unflexibel. Z.B. ist es jetzt schon so, dass ich den nfsserver und nfs-utils nicht bauen kann, wenn ich ihn nicht mit configure enabled habe. Das macht das bugfixen und testen der Features für Leute wie mich, die eigentlich fast nichts in ihren Images drin haben, unnötig kompliziert.

Wenn du das also machst, dann sollten diese configure-Optionen IMVHO nur die default-flashtargets die im "make image" aufgerufen werden ändern, aber keinesfalls, wie jetzt im "if ENABLE_NFSSERVER"-Fall, die ganzen Regeln deaktivieren.

[rhabarber1848]

Ich finde das nicht soo dringend.

Dringend nicht, aber nice to have

Die busybox-config passt man sich ja eh an

Darauf möchte ich eigentlich verzichten, deshalb dieser Patch.

und für alles andere gibt es ja schon flash-targets

Ebenso will ich auf customization-Skripts soweit wie möglich verzichten.

aber keinesfalls, wie jetzt im "if ENABLE_NFSSERVER"-Fall, die ganzen Regeln deaktivieren.

Ich finde es auch merkwürdig, dass "if ENABLE_NFSSERVER" die targets
deaktiviert, das scheint aber was mit $FILES_FLASH_RW in
cdk/root/etc/Makefile.am zu tun zu haben.

Ich stelle mir meinen Patch so vor, dass er per m4 die Busybox-Config
um die Tools erleichtert, die im Original vorhanden sein sollen. Beim
Kompilieren werden dann die jeweiligen flash-* targets aufgerufen.
Die Komplexität des CDK dürfte dadurch nicht ansteigen, ebenso ist
Rückwärtskompatibilität für mich ein wichtiger Punkt.

[Barf]

Eigentlich keine schlechte Idee. Vgl. mein Beitrag. Der Name ist aber schlecht gewählt, weil irreführend IMHO. Möglicherweise bekommt der Benutzen den Eindruck, dass nicht in --with-tools gelistete tools nicht vorhanden sind. Vorschlag: --with-standaloneversions=...

[rhabarber1848]

Vorschlag: --with-standaloneversions=...

Gute Idee, ich war mit --with-tools auch nicht so zufrieden.

[GetAway]

@rhabarber1848

Hi,
kommt da noch etwas von Dir? Ich fand die Idee sehr gut.
Wenn ja, gilt das dann auch für die Plugins (tuxmail, tuxtxt, tuxcal, etc.)?

[rhabarber1848]

kommt da noch etwas von Dir?

Ja, dauert aber noch. Ich melde mich, wenn ich was habe.
Im Moment bin ich mit uClibc SVN HEAD (1, 2), esound
und meinem Privatleben beschäftigt.

[GetAway]

Danke für die Info, wollte Dich nicht treiben.
Im Prinzip wollte ich nur wissen, ob die Plugins dann
auch da mit reinfallen.

[rhabarber1848]

PS: --with-tools=dboxshot,fbshot wäre natürlich auch möglich.
Es geht nicht nur darum, Features der Busybox zu ersetzen.

Das betrifft auch die targets flash-tuxmail, flash-tuxtxt u.ä., die z.Zt.
in cdk/make/flashroot.mk für alle Images ausgeführt werden.

Targets, wie die o.g. flash-fbshot oder flash-dboxshot müssen z.Zt.
per customization-Skript beim Imagebau aktiviert werden und sollen
von diesem Patch ebenfalls de-/aktivierbar sein.

Somit kann durch Weglassen von tuxtxt in der neuen Option z.B. das
Tuxtxt-Plugin deaktiviert werden. Soweit meine Pläne...

[rhabarber1848]

OK, "make flash-procps" müsste mal jemand machen, das gibt es noch nicht

Kleiner Hinweis dazu:

Ein Flashimage mit "make yadd-neutrino flash-neutrino-squashfs-all" gebaut
ist größer als wenn es mit "make flash-neutrino-squashfs-all", jeweils direkt
nach cdk/configure, gebaut wurde.

Das liegt an diesem Code:
http://cvs.tuxbox-cvs.sourceforge.net/c ... iew=markup

Code: Alles auswählen

	if [ -e $(targetprefix)/lib/libproc-*.so ]; then \
		cp -d $(targetprefix)/lib/libproc-*.so $</lib; \
		chmod +w $</lib/libproc-*.so; \
	fi

der immer aufgerufen wird, auch wenn ps/top im Flashimage die Busybox-Versionen sind.

[rhabarber1848]

kommt da noch etwas von Dir?

Eine erste Testversion des Patches läuft hier bereits,
allerdings habe ich die Option in --with-features umbenannt.

Um der Optionitis Einhalt zu gebieten, ersetzt der Patch die Option
--enable-cdkVcInfo durch --with-features=cdkvcinfo

Wäre es in Ordnung, wenn darüberhinaus die Optionen
--enable-esd
--enable-lirc
--enable-sqlite
--enable-ipkg
ebenfalls über --with-features abgehandelt werden?

Aktuell werden folgende Werte unterstützt:

cdkvcinfo, fbshot, dboxshot, msgbox, shellexec, lcshot (dbox2-only), tuxwetter, sysinfo, dropbear, dvbsnoop, tuxcal, procps

Diese Liste ist bei weitem noch nicht vollständig, es fehlen noch lcdcirc,
satfind und viele andere targets, --with-features=lcshot wird in nicht-
dbox2-Umgebungen einfach ignoriert.

Die Option procps sorgt dafür, dass in Busybox die applets top und ps
deaktiviert und diese aus dem procps-Paket installiert werden, das gilt
für Yadd und Flash-Images, keine customization-Skripts mehr nötig!
Änderung: Im Yadd wird im Moment immer das procps-Paket genutzt,
dies ist nun nur noch der Fall, wenn --with-features=procps genutzt wird.

Die Plugins tuxwetter und sysinfo werden nach dem commit des Patches
nicht mehr standardmäßig in Flashimages installiert, sondern nur noch
per --with-features=tuxwetter,sysinfo oder den altbekannten customi-
zation-Skripts, wie hier bereits besprochen.

Ich werde den Patch demnächst veröffentlichen, hätte aber gerne
vorher noch einige Rückmeldungen zu den o.g. Ideen.

[Striper]

Ich find die Idee sehr gut und würde gern den Patch testen. Wollte eh grad neu kompilieren. ;)

Kommt da später tuxmail, tuxcom etc... auch dazu? Dann könnte man wirklich per Default erstmal alles aus dem Image lassen und nur das hinzufügen was mit "--with-features=" aktiviert wird. Da wurde ja im Plugin Thread schon darüber diskutiert. Evtl. ist es sinnvoll die Sache der Übersichtlichkeit halber aufzudröseln in "--with-features=" und "--with-plugins=".

Super wäre auch so eine ähnliche Funktion für die Sprachen. Damit die nicht immer alle im Image landen. Z.B. "--with-languages=".

P.S. Meine customize Scripte werden immer kleiner. Find ich gut! :)

[rhabarber1848]

Dann könnte man wirklich per Default erstmal alles aus dem Image lassen und nur das hinzufügen was mit "--with-features=" aktiviert wird.

Von solch tiefgreifenden Eingriffen scheue ich noch etwas zurück und
warte ab, wie die Diskussion dazu läuft.

http://www.tuxbox-cvs.sourceforge.net/f ... 03#p374003

@rhabarber1848
Einige Plugins von SnowHead lassen sich auch über das Flexmenü starten. Dazu gehören dann
eigentlich noch spezielle Steuerskripte, die mit ins CVS gelegt werden sollten. Bei Clock wäre
es dann das Skript "cops". Ich denke die Steuerskripte gehören, der Vollständigkeit halber, dazu.

Das habe ich nicht vergessen, nur habe ich es mir für den Moment aufgehoben,
wo --with-features=shellexec im CVS ist, dann kann nämlich in Abhängigkeit dieser
Option die Menükonfiguration des Flexmenüs beim Kompilieren erstellt werden.

[rhabarber1848]

Dann könnte man wirklich per Default erstmal alles aus dem Image lassen und nur das hinzufügen was mit "--with-features=" aktiviert wird.

Von solch tiefgreifenden Eingriffen scheue ich noch etwas zurück und
warte ab, wie die Diskussion dazu läuft.

Ich habe --with-features jetzt so geschrieben, dass alle derzeitigen Standard-
features im Image landen, wenn --with-features nicht verwendet wird.
Die aktuelle Liste meines Patches sieht dann so aus:

enable_cdkvcinfo=no
enable_dboxshot=no
enable_dropbear=no
enable_dvbsnoop=no
enable_dvbsub=yes
enable_fbshot=no
enable_lcshot=no
enable_msgbox=no
enable_procps=no
enable_satfind=no
enable_shellexec=no
enable_sysinfo=yes
enable_tuxcal=no
enable_tuxcom=yes
enable_tuxmail=yes
enable_tuxtxt=yes
enable_tuxwetter=yes

Wenn --with-features verwendet wird, werden nur die dort angegebenen
Features Bestandteil des Images. Alles andere, auch die in der obigen Liste
aufgeführten Features, kommen nicht ins Image.

[rhabarber1848]

Wäre es in Ordnung, wenn darüberhinaus die Optionen
--enable-esd
--enable-lirc
--enable-sqlite
--enable-ipkg
ebenfalls über --with-features abgehandelt werden?

Meinungen hierzu wären noch wichtig.

[bellum]

Ich werde den Patch demnächst veröffentlichen, hätte aber gerne
vorher noch einige Rückmeldungen zu den o.g. Ideen.

hört sich doch alles gut an, mir fällt jetzt nichts ein was dagegenspräche...

Gruß bellum

[Grabber66]

Wäre es in Ordnung, wenn darüberhinaus die Optionen
--enable-esd
--enable-lirc
--enable-sqlite
--enable-ipkg
ebenfalls über --with-features abgehandelt werden?

Meinungen hierzu wären noch wichtig.

Find die Idee echt gut, auch wenn diese 4 auch noch mit reinfallen, dann wird es einheitlicher, finde ich.

[rhabarber1848]

Evtl. ist es sinnvoll die Sache der Übersichtlichkeit halber aufzudröseln in "--with-features=" und "--with-plugins=".

Wo ist da genau die Trennlinie? Sysinfo und Tuxwetter z.B. sind stand-alone binaries,
die aber über ein shellstarter-Plugin aufgerufen werden. Sie tauchen also in der Plugin-
Liste auf, sind technisch gesehen aber keine Plugins.
Ich würde daher gerne alles* in die Option --with-features= packen, um einerseits
Missverständnissen vorzubeugen und andererseits die Anzahl der cdk/configure-
Optionen klein zu halten.

* Klassische Plugins wie Tuxtxt, Tools wie dboxshot, Zwitterplugins wie Sysinfo und
3rd-party Programme wie Esound, Sqlite etc.

[dietmarw]

Evtl. ist es sinnvoll die Sache der Übersichtlichkeit halber aufzudröseln in "--with-features=" und "--with-plugins=".

Wo ist da genau die Trennlinie? Sysinfo und Tuxwetter z.B. sind stand-alone binaries,
die aber über ein shellstarter-Plugin aufgerufen werden. Sie tauchen also in der Plugin-
Liste auf, sind technisch gesehen aber keine Plugins.
Ich würde daher gerne alles* in die Option --with-features= packen, um einerseits
Missverständnissen vorzubeugen und andererseits die Anzahl der cdk/configure-
Optionen klein zu halten.

* Klassische Plugins wie Tuxtxt, Tools wie dboxshot, Zwitterplugins wie Sysinfo und
3rd-party Programme wie Esound, Sqlite etc.

[Striper]

Evtl. ist es sinnvoll die Sache der Übersichtlichkeit halber aufzudröseln in "--with-features=" und "--with-plugins=".

Wo ist da genau die Trennlinie?

Stimmt, da eine klare Trennlinie zu ziehen wird schwierig und ist, wenn ich jetzt so drüber nachdenke, auch nur unnötig kompliziert.

Wenn --with-features verwendet wird, werden nur die dort angegebenen
Features Bestandteil des Images. Alles andere, auch die in der obigen Liste
aufgeführten Features, kommen nicht ins Image.

*thumbsup*

[Barf]

Erstmals bin ich etwas verwirrt: Der Thread hat angefangen mit einer Option um standalone versionen von einige Tools auszuwählen (top, ps) (davon scheint nichts geworden zu sein), ist danach eine allgemeine Umkrämplung der configure-Optionen geworden. Erstmals (falls ich mich richtig erinnere) genannt "Vorschlag für neuen Patch: --with-tools=...", danach "Vorschlag für neuen Patch: --with-standaloneversionjs=...", und schliesslich "Vorschlag für neuen Patch: --with-features".

Mit leserlige Threads verstehe ich etwas Anderes.

Mein Verständniss (der vorgeschlagene Patch konnte ich nicht finden) ist dass es fast ausschliesslich um ein Syntaxänderung handelt:

Um der Optionitis Einhalt zu gebieten, ersetzt der Patch die Option
--enable-cdkVcInfo durch --with-features=cdkvcinfo

Wäre es in Ordnung, wenn darüberhinaus die Optionen
--enable-esd
--enable-lirc
--enable-sqlite
--enable-ipkg
ebenfalls über --with-features abgehandelt werden?

"Optionitis" bekämpft man indem man existierende Optionen sorgfälligt für Redundanz, Überflüssigkeit, und ins besonderes Konsistenz in Syntax und Semantik der Benutzung überprüft. Nicht durch eine syntaktische Änderung. Ausserdem, In der Tat kann man eine Liste wie

Code: Alles auswählen

enable_cdkvcinfo=no
enable_dboxshot=no
enable_dropbear=no
enable_dvbsnoop=no
enable_dvbsub=yes
enable_fbshot=no
enable_lcshot=no
enable_msgbox=no
enable_procps=no
enable_satfind=no
enable_shellexec=no
enable_sysinfo=yes
enable_tuxcal=no
enable_tuxcom=yes
enable_tuxmail=yes
enable_tuxtxt=yes
enable_tuxwetter=yes

leicht in einem ./configure-Kommandozeile mittels (z.B) Standardtools wie xargs und sed umwandeln.

Die Optionsstruktur in den Automake/autoconfigure-Toolchain ist durchgedacht und etabliert. Sie sind natürlich auch kein heiliger Graal, der nicht verbessert werden kann. Änderungen sollen aber dann wirkliche Verbesserungen darstellen, und nicht nur cooler aussehen. Der vorgeschlagene Syntaxänderung hat, durch Inkompatibilitäten, mehr Nachteile als Vorteile. Deswegen:

[Striper]

Erstmals bin ich etwas verwirrt: Der Thread hat angefangen mit einer Option um standalone versionen von einige Tools auszuwählen (top, ps) (davon scheint nichts geworden zu sein), ist danach eine allgemeine Umkrämplung der configure-Optionen geworden. Erstmals (falls ich mich richtig erinnere) genannt "Vorschlag für neuen Patch: --with-tools=...", danach "Vorschlag für neuen Patch: --with-standaloneversionjs=...", und schliesslich "Vorschlag für neuen Patch: --with-features".

Mit leserlige Threads verstehe ich etwas Anderes. :-?

Ich kann den Thread gerne splitten. Das sollte das geringste Problem sein.

Änderungen sollen aber dann wirkliche Verbesserungen darstellen, und nicht nur cooler aussehen.

In meinen Augen hat der Patch nur Vorteile.

- einfaches integrieren der echten proc file system utilities ins Image ohne große Stunts in den customize Scripten
- generell weniger Bedarf an customize Scripten da vieles übersichtlich durch den configure Aufruf erledigt wird

Der vorgeschlagene Syntaxänderung hat, durch Inkompatibilitäten, mehr Nachteile als Vorteile.

Kannst Du das genauer ausführen? Ich sehe da nämlich keine Inkompatibilitäten für mich als Nutzer.

[Barf]

Ich kann den Thread gerne splitten. Das sollte das geringste Problem sein.

Das wurde wohl kaum hilfen, weil das Problem von inhaltliger Art ist. Ich möchte wissen was mit den standbyversionspatch geworden ist (da hilft wohl nicht ein Splitten). Ausserdem ist das nacheditieren fast immer ein Gräuel.

- einfaches integrieren der echten proc file system utilities ins Image ohne große Stunts in den customize Scripten

Ich habe nichts gegen, falls jemanden dies ermöglicht. Weil "der Patch" nicht vorliegt kann ich es nicht evaluieren, und "dagegen" bedeutet natürlich nicht dass es keine benutzbare Teile drin gibt.

- generell weniger Bedarf an customize Scripten da vieles übersichtlich durch den configure Aufruf erledigt wird

Ist genau so gut mit dem alten --enable-foo als mit dem neuen --with-feature=foo getan.

Der vorgeschlagene Syntaxänderung hat, durch Inkompatibilitäten, mehr Nachteile als Vorteile.

Kannst Du das genauer ausführen? Ich sehe da nämlich keine Inkompatibilitäten für mich als Nutzer.

Wirklich so schwierig? Bedarf für Neulernen sowie Änderung von vorhandene Skripte? Nicht zu vergessen: Die Autotools sind in tausende von Softwarepakete benutzt, Leute wissen wie --with-FOO und --enable-BAR funktionieren, dagegen nicht --with-feature.