Erstellt vor 7 Jahren

Zuletzt geändert vor 3 Jahren

#1269 assigned enhancement

Neue Struktur für Paket Verzeichnis (und menuconfig)

Erstellt von: oliver Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: packages Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

From a quick look I moved around 30 packages from testing to stable. Are there more suggestions of stable packages (mostly binary only or packges with webinterface)?

Anhänge (13)

move_testing_packages.patch (5.0 KB) - hinzugefügt von oliver vor 7 Jahren.
binary_only_category.patch (7.1 KB) - hinzugefügt von oliver vor 7 Jahren.
config_categories.patch (10.6 KB) - hinzugefügt von M66B vor 7 Jahren.
Variant #3
genin.patch (18.2 KB) - hinzugefügt von cuma vor 7 Jahren.
versuch die Kategorien in die Pakete zu verlagern und das Menü zu generien
geninV2.patch (17.9 KB) - hinzugefügt von cuma vor 7 Jahren.
genin_v3 (2.4 KB) - hinzugefügt von MaxMuster vor 7 Jahren.
Sorry, one line was missing…
geninV3.patch (23.2 KB) - hinzugefügt von cuma vor 7 Jahren.
(V2 + Unterkategorien)
geninV3.gen (6.0 KB) - hinzugefügt von cuma vor 7 Jahren.
categories.patch (63.4 KB) - hinzugefügt von MaxMuster vor 7 Jahren.
Patch für die "Kategorisierung" der Pakete (Arbeit von M66B)
genin_v4 (4.9 KB) - hinzugefügt von MaxMuster vor 7 Jahren.
Neuer Versuch von "genindex"
subcat.txt (302 Byte) - hinzugefügt von MaxMuster vor 7 Jahren.
… und noch eine "Versuchsdatei" für make/subcat.txt
generated.Config.in (6.5 KB) - hinzugefügt von MaxMuster vor 7 Jahren.
… sowie das "Ergebnis" des Durchlaufes …
Config.test (2.3 KB) - hinzugefügt von kriegaex vor 6 Jahren.
Kconfig-Datei mit mehrfach definierten Symbolen

Alle Anhänge herunterladen als: .zip

Änderungshistorie (80)

Geändert vor 7 Jahren durch oliver

comment:1 Geändert vor 7 Jahren durch cuma

Ich finde die Unterteilung von Testing und Packages überflüssig. Es gibt nur ein paar Pakete mit bekannten Problemen, die könnte man in ein eigenes Untermenü schieben bzw nach Unstable.
Außerdem gab schon öfter von verschiedenen Personen die Idee die Pakete in Kategorien zu unterteilen…

Was ich länger genutzt hab ohne Probleme festzustellen: subversion rrdtool owfs httpry iptraf davfs2 autofs minidlna minidlna oidentd opendd nmap

comment:2 Geändert vor 7 Jahren durch schuettecarsten

Dafür!

comment:3 Geändert vor 7 Jahren durch er13

Bin auch für thematische Kategorien…

Bin mir zwar noch nicht ganz sicher, denke aber, dass es besser wäre, wenn es keine Kategorie "Unstable packages" geben würde. Stattdessen sollte es eine menuconfig-Option "Show unstable packages" geben, jeses unstable-Package sollte von dieser abhängen.

comment:4 Geändert vor 7 Jahren durch oliver

Sollen wir bei Auswahl dieser "unstable" Option die Pakete dann noch Kennzeichnen? Oder einfach nur anzeigen?

comment:5 Geändert vor 7 Jahren durch M66B

There have been a lot of packages produced that are not in trunk (yet). So, my question is why are known unstable packages "uberhaupt" in trunk? Maybe it is better to have these available only as patch in a ticket, so anyone that wants to try these packages can read first what the status is.

comment:6 Geändert vor 7 Jahren durch cuma

@M66B: Es gibt Pakete die auf manchen Boxen ohne Probleme funktionieren, auf anderen Boxen jedoch nicht. zb sis-pm (Problem auf x1xx), radvd (Problem auf x2xx) und digitemp (Problem auf x1xx). Dazu gibt es Tickets
Falls unstable wegfällt sollte aber unbedingt eine Kennzeichnung in Klammern im Namen dahinter. Ganz überzeugt bin davon aber noch nicht!

comment:7 Geändert vor 7 Jahren durch M66B

@cuma: should availability (the possibility to select a package) not depend on the box type then? (if possible of course)

comment:8 Geändert vor 7 Jahren durch cuma

Das wäre kein Problem. Allerdings nutze ich digitemp auf meiner 7270, wenn auch noch ~24h der Ram voll ist und ein Reboot nötig

comment:9 Geändert vor 7 Jahren durch M66B

@cuma: I see what you mean. In that case there should ideally be an option to select unstable packages for the selected box type, even if they are hidden normally, because you cannot patch something in that is already in trunk.

I think it is useful to know what packages are stable for what box type. I guess the current show unstable option shows all unstable packages even if some of them are actually stable for the selected box type.

comment:10 Geändert vor 7 Jahren durch oliver

Eigentlich wollte ich hier keine stundenlange Arbeit investieren, da die Kategorisierung der Pakete für 1.3 auf der Agenda steht. Wegen mir können wir es für 1.2 auch lassen wie es ist, wenn die Mehrheit der Meinung ist, dass es keinen Sinn macht einzelne Pakete von testing nach stable zu verschieben.

edit:
Wie wäre es für 1.2 mit dem Abschaffen von testing und wir machen binary only als weitere Kategorie?

Zuletzt geändert vor 7 Jahren von oliver (vorher) (Diff)

comment:11 Geändert vor 7 Jahren durch cuma

Vielleicht findet sich sonst jemand der das macht. Wenn es vor 1.2 fertig ist wäre doch prima

comment:12 Geändert vor 7 Jahren durch oliver

In (r6749)

  • packages: Mark as binary only and unstable
    • white space fixes
  • refs #1269

Geändert vor 7 Jahren durch oliver

comment:13 Geändert vor 7 Jahren durch oliver

Der angehängt Patch verschiebt alle nicht unstable packages mit Webinterface nach Standard und die Binary only nach binary only. Ich hoffe ich habe keins vergessen.

comment:14 Geändert vor 7 Jahren durch oliver

Gibt's noch Kommentare zum zweiten angehängten Patch?

Variante 1 oder Variante 2? Oder lieber so lassen wie es ist?

Geändert vor 7 Jahren durch M66B

Variant #3

comment:15 Geändert vor 7 Jahren durch M66B

My proposition: categories.

I am always searching in the fortunately long list of packages. After a while you get used to it, but this makes it much easier IMHO.

Starting points:

  1. No separate categories for stable/testing, everything is testing ;-)
  2. No separate category for WebIF or not, a lot of packages do have a WebIF and are not in the current WebIF list (in the beginning I was surprised by this)

I have left unstable untouched, but see my previous note about these.

This was a lot of work, so be kind!

And to give another opinion: every package out there in a patch should be in trunk (if they work of course).

comment:16 Geändert vor 7 Jahren durch cuma

Ich finde das ist ein guter Anfang :) Es könnten aber etwas weniger Kategorien sein, da in manchen nur wenige Pakete sind. Wegfallenlassen von "Webinterface" finde ich gut. Man könnte dann noch "Unterpakete" machen, zB vnstat → vnstat-cgi oder transmission → transmission-cgi.

comment:17 Antwort: Geändert vor 7 Jahren durch MaxMuster

Finde ich auch eine gute Idee, war sicher viel Arbeit, danke!
Ich wäre aber auch für etwas weniger (Ober-)Kategorien (Netzwerk, Medien, Sicherheit …), wo man dann ggf. noch "Unterkategorien" einführen.
OpenWRT hat (als Anlehnung/Anregung ;-)) admin, devel, ipv6, lang, libs, mail, multimedia, net, skels, sound, utils (sowie noch Xorg)

comment:18 als Antwort auf: ↑ 17 Geändert vor 7 Jahren durch M66B

Replying to MaxMuster:

Ich wäre aber auch für etwas weniger (Ober-)Kategorien (Netzwerk, Medien, Sicherheit …)

I am aware that some categories have just a few packages, but this leaves room for all those packages that are available as patch only now.

"Unterpakete" ist eine gute Idee: next release.

If somebody makes a (sub)category scheme I am willing to go through the packages again for a improved patch. Also, let me know which packages are in the wrong category (I was not sure about the function of each and every package).

Geändert vor 7 Jahren durch cuma

versuch die Kategorien in die Pakete zu verlagern und das Menü zu generien

comment:19 Geändert vor 7 Jahren durch M66B

@cuma: I think it is a very good idea to automate the categories!

Question: can this work for "Unterpakete" too?

I see one disadvantage: we have to go through all .mk files, but this is only once.

comment:20 Antwort: Geändert vor 7 Jahren durch cuma

Unterpakete sind möglich, da dies über das "depends" in den Config.in gemacht wird. Unterkategorien (noch) nicht
Hier eine verbesserte Version die statt 6 Sekunden nur noch 2 braucht

Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

Geändert vor 7 Jahren durch cuma

comment:21 Geändert vor 7 Jahren durch er13

Would not that be better if we

  • create a subdirectory for each category
  • "svn move" each package to the corresponding subdirectory
  • and generate menuconfig based on these category-subdirectories

We already have one category/subdirectory: libs ;-)

OpenWRT does something similar, we can probably "steal" some code from them…

comment:22 Geändert vor 7 Jahren durch cuma

Ist auch eine Idee, ich finde es aber besser wenn alle Packages in einem Verzeichnis liegen. Die Beziehungen der Unterkategorien könnte man über eine Textdatei definieren
EDIT: Wie hast du vor Unterkategorien abzubilden?

Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

comment:23 Geändert vor 7 Jahren durch oliver

The packages in OpenWRT trunk/ are not categorized by directories. Only the ones in packages/.

comment:24 als Antwort auf: ↑ 20 Geändert vor 7 Jahren durch MaxMuster

Replying to cuma:

Hier eine verbesserte Version die statt 6 Sekunden nur noch 2 braucht

Vielleicht magst du mal meine Version bei dir testen? Die ist sicher auch nicht optimal, ist aber bei mir schneller und kommt ohne "eval" aus…

Geändert vor 7 Jahren durch MaxMuster

Sorry, one line was missing…

comment:25 Geändert vor 7 Jahren durch cuma

Optimieren kann man sicherlich noch. Meine V2 benötigt ~2 Sekunden bei mir. Deine ist langsamer …

for x in V1 V2 V3 MM; do echo $x; time ~/Desktop/genin${x}.sh >/dev/null; done

V1
real	0m5.820s
user	0m0.403s
sys	0m10.003s


V2
real	0m2.266s
user	0m0.612s
sys	0m1.711s  <-

V3
real	0m2.300s
user	0m0.553s
sys	0m1.880s

MM
real	0m2.476s
user	0m0.464s
sys	0m2.191s <-
Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

Geändert vor 7 Jahren durch cuma

(V2 + Unterkategorien)

Geändert vor 7 Jahren durch cuma

comment:26 Geändert vor 7 Jahren durch M66B

There are about 90 new packages that could be added and that could fill the somewhat empty categories.

comment:27 Geändert vor 7 Jahren durch M66B

Is the script finished enough to start modifying the .mk files?

Which list of categories should be used?

I am still willing to undertake this action …

comment:28 Geändert vor 7 Jahren durch cuma

Ich denke das braucht noch Zeit. Die erste Idee dazu war schon vor ~ 2 Jahren …

comment:29 Geändert vor 7 Jahren durch oliver

Ich finde es schön, dass du (M66B) daran arbeiten willst und auch das Skript von cuma funktioniert schon so weit, dass wir das angehen könnten.

In meinen Augen gibt es jedoch noch einige Punkt zu klären:

  • Ich weiß nicht, ob ich mit der jetzigen Lösung schon glücklich bin. Zum einen dürfte klar sein, dass wir die ganzen neuen Pakete nicht einfach in den trunk einchecken können, da die Ladezeit für menuconfig (und jedes anderen make) mit der Anzahl der Pakete ansteigt. Deshalb die Idee mit der dynamischen Variante.
  • Wir benötigen also ein packages/-Verzeichnis im svn in das die neuen Pakete eingecheckt werden und bei Bedarf vom Benutzer in den trunk geholt werden können. Darüber hinaus müssen wir uns natürlich überlegen, ob wir evtl. vorhandene Pakete aus dem trunk nehmen und nach packages/ verschieben wollen.
  • Derzeit haben wir noch keine genauen Anforderungen an das zukünftige Aussehen der Paket-Dateien aufgestellt. So wäre es denkbar, dass wir, wie in OpenWRT, die Config.in mit in die .mk Datei aufnehmen. (Hat natürlich diverse pros und contras.)
  • Die Libraries sollen über kurz oder lang auch eigene Verzeichnisse erhalten, da es langsam etwas unübersichtlich in dem Verzeichnis wird.
  • OpenWRT managed auch gleich die Info-Erstellung für die opkgs in diesem Schritt. Wenn wir in Zukunft dynamische Pakete unterstützen wollen, dann müssen wir uns auch damit befassen.

Deshalb stellt sich mir die Frage, ob es Sinn macht jetzt drauf los zu ändern. Nicht, dass der Aufwand dann unnötig war, weil wir uns doch für eine andere Lösung entscheiden. Falls die jetzt gewählte Lösung für die zukünftigen Anpassungen erweiterbar ist und die investierte Zeit nicht verschwendet, dann können wir wegen mir auch gleich Änderungen einpflegen.

comment:30 Geändert vor 7 Jahren durch schuettecarsten

Nur so als Idee:

Wäre es nicht denkbar, für die unstable-Packages im "trunk" ein Verzeichnis "unstables" anzulegen, und dann eine Art "make unstable-menuconfig" zu bauen, in dem man erst einmal die "unstable"-Packages auswählen muss, die man überhaupt haben will. Im "make menuconfig" würden dann nur die Unstable-Packages berücksichtigt, die man vorher ausgewählt hat…..?

comment:31 Geändert vor 7 Jahren durch cuma

Eigentlich müssten wir zuerst nur wissen wie wir die Kategrien in der .mk speichern. Der Rest wird sich dann ergeben wenn es soweit ist.

  • Wieviele Eben soll es geben? (1, 2, oder rekursiv/unendlich)
  • Wird die Kategriestruktur in einer unabhängigen Datei (wie ich es gemacht hab) hinterlegt oder wird der ganze Kategrier-Baum in der .mk festgelegt?
  • MaxMusters Idee den IFS zu ändern hat den Vorteil dass man alle Zeichen in der Kategoriebeschreibung nutzen kann. Damit ist im Moment aber nur 1 Ebene möglich (und damit schon langsamer ;-) )

comment:32 Geändert vor 7 Jahren durch MaxMuster

Zwei Ansichten sähe ich:

  • Universell: Kategorien im .mk-File, die "beliebig" zu schachteln sind (wenn "VPN" Untergruppe von "NET" ist, müssen alle VPN-Pakete "unter" NET→VPN sein). Frage: Wo stellt man das ein? Es müsste quasi einen "Parent"-Verweis geben, der aber "zentral" sein müsste (ähnlich wie die menu.txt, aber ich würde da Paare "KAT—Parent_KAT" reinnehmen).
  • Simpler: Alles in einen Eintrag, so könnte durchaus eine "feste Eintragung" wie $(PKG)_CATEGORY=network/vpn dort stehen, wenn man das braucht.

Wirklich simpel und schnell (aber eben nicht mehr flexibel) wäre doch eine statische Unterteilung in Kategorien-Ordner oder der ursprüngliche Ansatz von M66B, die Kategorien in der Datei make/Config.in fest vorzugeben.
Ist halt immer die Abwägung "schön/flexibel" (aber aufwendiger und langsamer) gegen "simpel/schnell" und die Frage, wie häufig tatsächlich Umorganisationen sind.

Die IFS Änderung war übrigens nur da, um die "SPACES"-Umwandlung zu umgehen ;-)

comment:33 Geändert vor 7 Jahren durch oliver

Statisch ist meiner Meinung nach aufgrund der oben genannten Gründe nicht machbar. Mal wieder ein Beispiel von OpenWRT:

define Package/vpnc
  SECTION:=net
  CATEGORY:=Network
  DEPENDS:=+libgpg-error +libgcrypt +kmod-tun +ip
  TITLE:=VPN client for Cisco EasyVPN
  URL:=http://www.unix-ag.uni-kl.de/~massar/vpnc/
  SUBMENU:=VPN
endef

comment:34 Geändert vor 7 Jahren durch cuma

Statisch finde ich auch nicht gut. Mit $(PKG)_CATEGORY=network/vpn wäre ein Umbenennen von "network" nicht so einfach. Außerdem hätte man ein nutzbares Zeichen "verloren". Da gefällt mir section/categorie schon besser. Dies würde aber dann max 2 Ebenen bedeuten. Wobei man dann auch die "Sektionen" in eine Datei auslagern könnte was das Parsen beschleunigen würde :)
@MaxMuster: Du hast doch die Variablennamen nicht generiert, womit dann doch alle Zeichen nutzbar sind?

Zuletzt geändert vor 7 Jahren von cuma (vorher) (Diff)

comment:35 Geändert vor 7 Jahren durch MaxMuster

Ich habe mal einen neuen "Versuch" angehängt, der den "dynamischen" Ansatz komplett durchführt.

Es gibt eine Datei "make/subcat,txt", in der Einträge der Art "Parent##Child" gemacht werden können, prinzipiell auch mehrere Ebenen:

AA##B
BB#C
C##D

sollte dazu führen, dass B Untermenü von AA ist und unterhalb von BB ist C, darunter D.

Ich habe die erste Einordnung von M66B dazu mal in die Dateien reingepackt (siehe Patch)…

Geändert vor 7 Jahren durch MaxMuster

Patch für die "Kategorisierung" der Pakete (Arbeit von M66B)

Geändert vor 7 Jahren durch MaxMuster

Neuer Versuch von "genindex"

Geändert vor 7 Jahren durch MaxMuster

… und noch eine "Versuchsdatei" für make/subcat.txt

Geändert vor 7 Jahren durch MaxMuster

… sowie das "Ergebnis" des Durchlaufes …

comment:36 Geändert vor 7 Jahren durch oliver

  • Meilenstein von freetz-1.2 nach freetz-1.3 geändert
  • Status von new nach assigned geändert
  • Verantwortlicher oliver gelöscht

Sehe ich das richtig, dass der allgemeine Tenor "Wenn Änderungen dann gleich richtig!" ist und das Ticket daher nach 1.3 geschoben werden kann?

comment:37 Geändert vor 6 Jahren durch oliver

  • Zusammenfassung von Packages testing->stable nach Neue Struktur für Paket Verzeichnis (und menuconfig) geändert

comment:38 Geändert vor 6 Jahren durch kriegaex

Gemäß der Gespräche auf der FreetzConf haben wir vor, uns die OpenWRT-Mechanik mal genauer anzusehen (bisher ohne Beschluß, das auch definitiv so umzusetzen - erst mal lernen).

Außerdem hatte ich die Idee eines Tagging-Ansatzes, der uns von einer starren, streng hierarchischen Menüstruktur insofern befreien würde, als es uns erlauben würde, ein Paket mehreren Kategorien (Tags) zuzuordnen. Dazu wäre es aber erforderlich, das gleiche Symbol mehrfach definieren zu können in Kconfig. Die gute Nachricht nach einer ersten kurzen Exploration (vgl. Config.test) ist: Es geht grundsätzlich und ist auch so dokumentiert:

A config option can be defined multiple times with the same name, but every definition can have only a single input prompt and the type must not conflict.

Wenn man mal tools/config/mconf Config.test aufruft, sieht man sehr schön, wie das Auswählen eines der doppelten Symbole TEST_THREE bzw. TEST_FOUR dazu führt, daß es im jeweils anderen Untermenü ebenfalls ausgewählt ist. Analog dazu funktioniert das Abwählen. Gespeichert wird jedes Symbol nur einmal, wie man sich sehr schön in .config nach dem Speichern anschauen kann. Das Aufrufen der Hilfe zu einem der mehrfach definierten Symbole zeigt so etwas wie:

Symbol: TEST_FOUR [=y]
Type  : boolean
Prompt: Test 4
  Defined at Config.test:64
  Location:
    -> test category 1
Prompt: Test 4
  Defined at Config.test:77
  Location:
    -> test category 2
Zuletzt geändert vor 6 Jahren von kriegaex (vorher) (Diff)

Geändert vor 6 Jahren durch kriegaex

Kconfig-Datei mit mehrfach definierten Symbolen

comment:39 Geändert vor 6 Jahren durch MrTweek1987

Ich habe da mal einen Vorschlag, Man könnte langsam einige Packete aus der "testing" section verschieben. Zudem könnte man ja auch die Packete in neue Menüs verfrachten… :/

  • nhipt → webinterfaces
  • iptables-cgi → webinterfaces…
  • transmission-cgi → webinterfaces…

Packetauswahl

-stable

  • —System
  • —Netzwerk
  • —-ipv6 (Untermenü)
  • —Debugging
  • —Games (?) (Fortune)
  • —Shell-Tools
  • —Streaming
  • —Filesystem-Extensions (usb-root)

-testing

  • —System
  • —Netzwerk
  • —Debugging
  • —Streaming
  • —Shell-Tools (zb: mc)

-unstable

  • —System
  • —Netzwerk
  • —Debugging
  • —Shell-Tools

comment:40 Geändert vor 5 Jahren durch cuma

  • Meilenstein von freetz-1.3 nach freetz-future geändert

comment:41 Geändert vor 4 Jahren durch cuma

  • Meilenstein von freetz-future nach freetz-next geändert

comment:42 Geändert vor 4 Jahren durch cuma

In 10911:

add genin, by various authors (refs #1269)

comment:43 Geändert vor 4 Jahren durch cuma

Optimierungen und Kategorien kann jeder nach Bedarf hinzufügen

comment:44 Geändert vor 4 Jahren durch cuma

In 10912:

genen: python- ignorieren (refs #1269)

comment:45 Geändert vor 4 Jahren durch dileks

[ Moved from Ticket #2153 (duplicate) ]

Beyond lots of typos, I have seen this:

[ tools/genin ]

115	# build menus
116	SAVMENU=""

This should be SAVEMENU.

Please, check the correct spelling of "categories", "replacement", "happened", "whether", etc. In some comments, those words are written correct, some lines later misspelled.

Personally, I would like to have seen sth. like what OpenWrt has (see comment of er13 in #1269). But anyway, life is no musicbox.

[1] http://freetz.org/browser/trunk/tools/genin?rev=10912

comment:46 Geändert vor 4 Jahren durch cuma

Es wird momenatn nicht erkannt, wenn neue Verzeichnisse in make erstellt werden.
@er13: Könntest du eine md5 vom Inhalt von make erstellen und bei Änderungen make/*.in.generated löschen, um diese neu erstellen zu lassen?

comment:47 Geändert vor 4 Jahren durch er13

In 10993:

genin:

  • automatically regenerate Config.in.generated if necessary
  • refs #1269

comment:48 Geändert vor 4 Jahren durch er13

In 10994:

genin:

  • remove trailing whitespaces
  • refs #1269

comment:49 Geändert vor 4 Jahren durch er13

In 10995:

genin:

  • fix some typos (not all just the obvious ones)
  • refs #1269

comment:50 Geändert vor 4 Jahren durch er13

Könnte bitte jemand dokumentieren, was und wie genin macht oder noch besser es in irgendeiner anderen Sprache schreiben, die mehr für solche Aufgaben geeignet ist (weil bessere Daten-Strukturen anbietet, z.B. Python). Ich habe mir eine halbe Stunde den Code angeschaut und immer noch nicht verstanden, was da veranstaltet wird.

Mir persönlich wäre es peinlich solchen Code zu committen, die Qualität ist einfach miserabel. Lesbarkeit gleich 0 (pidgin-englishe Kommentare helfen da auch nicht weiter), Wartbarkeit von jemandem, der es nicht geschrieben hat, ebenso gleich 0.

Zuletzt geändert vor 4 Jahren von er13 (vorher) (Diff)

comment:51 Geändert vor 4 Jahren durch cuma

Ich bin ganz gut damit klar gekommen.
Davon abgesehen finde ich, dass das eins der am besten kommentierten Skripte in Freetz ist. Und es soll eigentlich noch weiterentwickelt werden, sieht nur nicht so aus, als ob jemand dazu Lust hätte

comment:52 Geändert vor 4 Jahren durch dileks

6 weeks past (see comment #45)… Beyond that typos, there is still SAVMENU="".

http://freetz.org/browser/trunk/tools/genin#L116

comment:53 Geändert vor 4 Jahren durch cuma

Einfach mal deut(sch)licher ausdrücken, dann versteht man gleich was du sagen wolltest

comment:54 Geändert vor 4 Jahren durch cuma

In 11001:

genin: fix typo. by dileks (refs #1269)

comment:55 Geändert vor 4 Jahren durch er13

@cuma: ich fand es sehr anstregend den Code zu lesen, insbesondere weil statt auf gescheite Datenstrukturen zu setzen, alles String-basiert ist mit irgendwelchen Trennzeichen, die nur demjenigen was sagen, der das geschrieben hat. Sobald ich Zeit dafür habe, werde ich mir eine andere Lösung überlegen.

Was aus meiner Sicht noch definitiv gemacht werden muss, ist die Trennung zwischen "Config.in.generated generieren" und "external.in.generated generieren". Das eine ist unabhängig von dem anderen. Es kann auch sein, dass wir external-Support für irgendein existierendes Paket hinzufügen ⇒ es muss a) erkannt werden (wird bisher nicht gemacht), b) es reicht in dem Fall nur die eine Datei zu generieren.

comment:56 Antwort: Geändert vor 4 Jahren durch er13

Nach meinen Kommentaren oben ist es wahrscheinlich kein Geheimnis mehr, dennoch oute ich mich hiermit nochmal ausdrücklich als ein Gegner von genin. Nicht von der Idee an sich, sondern von der aktuellen Umsetzung:

  • Unlesbar
  • Unwartbar
  • Enthält Ausnahmen/Sonderbehandlungen - bei manchen Paketen ist es völlig intransparent, warum ausgerechnet bei diesen
  • Erweckt den Eindruck generisch/flexibel zu sein, ist es aber nicht - geschnürt auf ${freetz_root}/make, funktioniert mit einem anderen Verzeichnis (z.B. ${freetz_root}/add-ons) nicht
  • Hierarchien müssen in einer Zusatzdatei definiert werden, anstatt sich irgendwie anders zu ergeben
  • Config.in.generated / external.in.generated nicht getrennt - wenn man es richtig abstrahiert, ist es eine Funktion, die 2 Mal (nur mit unterschiedlichen Parametern) aufgerufen wird
  • Umsetzung insgesamt u.U. komplexer als sie sein könnte
  • Automatische Neugenerierung beim Hinzufügen neuer Pakete bzw. neuer Pakete zu external bedarf faktisch redundanter Umsetzung der Logik in Bezug auf die Ausnahmen in den Makefile-Dateien

Bevor ich meine Idee weiter unten vorstelle, wollte ich jedoch grundsätzlich nochmal alle fragen, welche Anforderungen wir an genin stellen:

  • Wollen wir weiterhin statische Config.in's haben (statisch an der Stelle bedeutet, dass wir Config.in's händisch schreiben) und genin sich lediglich darum kümmert, diese zu so "inkludieren", dass die von uns gewünschten Kategorien entstehen, oder
  • Wollen wir analog OpenWrt gänzlich auf handgeschriebene Config.in's für Pakete verzichten und stattdessen diese generieren lassen und anschließend richtig, automatisiert "inkludieren".

Sofern wir den zweiten Bullet-Point uns nicht als Ziel setzen, so könnte die Umsetzung sehr einfach, leicht verständlich, wartbar, generisch (zumindest in meinem Kopf) sein. In etwa könnte sie so aussehen:

  • Die Kategorien/Unterkategorien werden durch Verzeichnisstruktur definiert (d.h. keine flache Struktur unter ${freetz_root}/make mehr)
  • Sofern der Name des Verzeichnisses nicht als Kategorie ausreicht, könnte in dem Verzeichnis eine Datei abgelegt werden, die den Namen der Kategorie im menuconfig enthält (z.B. Config.in.cat)
  • Umsetzung bestünde (vereinfacht ausgedrückt) in 'find ${packages_root} -name "${.in-Datei oder .in.libs-Datei}" | generate_menuconfig', könnte also sowohl auf add-ons, sf3978-Packages, oder auch Config.in, external.in, Config.in.libs, external.in.libs angewandt werden
  • In den .mk-Dateien müssen keine Category-Einträge gemacht werden, somit müssen auch keine .mk-Dateien gegrept werden
  • Oben erwähnte Config.in.cat könnte auch die Abhängigkeiten der gesamten Unterkategorie enthalten, sie könnte quasi den Anfang von einem menuconfig-menu enthalten (damit wären Ausnahmen für asterisk-* und python-* nicht mehr notwendig)
  • TODO: wie man Config.in.libs automatisch hierarchisch einbindet ist mir noch nicht ganz klar. Eine Lösung wäre, unter libs "category-only"-Verzeichnisse anzulegen und aus diesen Config.in.libs zu symlinken. Mit diesem Ansatz wäre auch das Einbinden eines Pakets unter mehreren Kategorien möglich, so wie Alexander das in comment:38 vorschlägt. So richtig gefallen tut mir diese Lösung allerdings nicht.

So, das wäre eine grobe Skizze. Jegliche Kritik ist willkommen ;-)

Außer der Kritik hätte auch nichts dagegen, wenn wir einen Schritt zurück machen und nochmal gemeinsam die Anforderungen an genin diskutieren. Momentan scheint es in meiner Wahrnehmung wie gesagt ein Tool zu sein, welches Config.in's einzelner Pakete in der von uns gewünschten Reihenfolge inkludiert und dabei ein paar menuconfig-menus definiert. Ist es alles, was genin tun soll oder wollen wir mehr?

comment:57 Geändert vor 4 Jahren durch dileks

For me it is not clear why genin was not discussed before it was committed… But anyway… This might be OT here, but I was asking myself for a long time why the Freetz-buildsystem has several make directories (make in root-dir and several subdirs with a make-dir)? Can you explain the mechanism? Is it possible to save these "extra" make-dirs? Can the rewrite consider this wish?

comment:58 Geändert vor 4 Jahren durch er13

@dileks: yes, this is off-topic here as it has nothing to do with automatic generation of Config.in & external.in.

comment:59 Geändert vor 4 Jahren durch cuma

Was das Skript macht finde ich gut: ersetzt make/Config.in die nicht mehr von Hand geändert werden muss
Wie es das macht: Kann bestimmt noch verbessert werden, schneller, in C - falls es jemand macht. Die Version im Trunk ist ist ein Mix aus diesem Ticket
Kategorien: Genau genommen auch egal *wie* das gemacht wird. Wobei es fraglich ist ob das überhaupt gebraucht wird, wenn niemand die Kategorien erstellt


Mir ist noch aufgefallen: Wenn man mehrmals "make clean" aufruft, gibts wegen den .generated einen Fehler

Zuletzt geändert vor 4 Jahren von cuma (vorher) (Diff)

comment:60 Geändert vor 4 Jahren durch er13

In 11016:

  • do not regenerate Config.in.cache while cleaning, fixes tools/parse-config fails because of missing Config.in.generated
  • refs #1269

comment:61 Geändert vor 4 Jahren durch cuma

In 11035:

genin: dont use "let", not available everywhere (refs #1269, #2184)

comment:62 Geändert vor 4 Jahren durch er13

In 11475:

genin:

  • reimplement the logic what is considered to be a package. From now on every directory containing a file named Config.in is considered to be a package directory. This is not the best logic, it's however consistent with the logic implemented here. The new logic makes it possible to create pseudo-packages containing just one file - either ${pkg}.mk or Config.in (useful in some cases). The old logic caused make to stuck in infinite loop in these cases.
  • refs #1269

comment:63 Geändert vor 4 Jahren durch er13

In 11480:

genin:

  • consider symbolic links while generating package list
  • refs #1269, refs #2184

comment:64 Geändert vor 4 Jahren durch er13

TODO: ändert man bei einem Paket $(PKG)_CATEGORY, so wird es nicht erkannt und Config.in.generated nicht neu erezugt.


TODO2: fügt man neue external.in files hinzu, so wird es ebenso nicht erkannt und external.in.generated nicht neu generiert.

Zuletzt geändert vor 4 Jahren von er13 (vorher) (Diff)

comment:65 Geändert vor 4 Jahren durch er13

Das hier gemeldete Problem betrifft auch dieses Ticket.

comment:66 als Antwort auf: ↑ 56 Geändert vor 4 Jahren durch er13

Replying to er13:

Nach meinen Kommentaren oben ist es wahrscheinlich kein Geheimnis mehr, dennoch oute ich mich hiermit nochmal ausdrücklich als ein Gegner von genin. Nicht von der Idee an sich, sondern von der aktuellen Umsetzung:

Würde mich freuen Feedback auf comment:56 zu bekommen…

comment:67 Geändert vor 3 Jahren durch er13

  • Meilenstein von freetz-next nach freetz-future geändert
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.