freifunk-franken
/
firmware
9
7
Fork 13
Code Issues 48 Pull Requests 7 Releases 17 Wiki Activity

packages/fff: split fff-gateway into fff-layer3-config and fff-layer3 #14

Closed
adschm wants to merge 2 commits from adschm:gatewayconfig into master
pull from: adschm:gatewayconfig
merge into: freifunk-franken:master
Conversation 18 Commits 2 Files Changed 19 +58 -15
adschm commented 2020-12-14 14:49:47 +01:00
Owner
Copy Link

configuregateway and it's gateway.d files represent a specific
functionality that other packages depend on. Thus, it is put into
a package of its own so dependencies can be expressed more properly.

configuregateway and it's gateway.d files represent a specific functionality that other packages depend on. Thus, it is put into a package of its own so dependencies can be expressed more properly.
adschm added the
layer3
packages/fff
 labels 2020-12-14 14:49:58 +01:00
ChristianD commented 2020-12-14 17:27:24 +01:00
Member
Copy Link

Ich wäre grundsätzlich dafür den Begriff Gateway bzw. die Abkürzung gw jetzt nicht mehr zu verwenden und neue Sachen gleich mit layer 3 oder l3 zu bennen. Wenn man danach noch fff-gateway unbenennt bleibt nur noch das configuregateway Script übrig das einen neuen Namen braucht.
Ich glaube wir haben das ja schonmal ausdiskutiert und sind zu dem Entschluss gekommen das wir Gateway so nicht mehr verwenden wollen.

Ich wäre grundsätzlich dafür den Begriff Gateway bzw. die Abkürzung gw jetzt nicht mehr zu verwenden und neue Sachen gleich mit layer 3 oder l3 zu bennen. Wenn man danach noch fff-gateway unbenennt bleibt nur noch das configuregateway Script übrig das einen neuen Namen braucht. Ich glaube wir haben das ja schonmal ausdiskutiert und sind zu dem Entschluss gekommen das wir Gateway so nicht mehr verwenden wollen.
adschm commented 2020-12-14 17:34:28 +01:00
Author
Owner
Copy Link

Dann wäre die meta-package "fff-layer3". Aber bei configuregateway willst du dann die Bezeichnung "gateway" beibehalten? Oder doch fff-layer3-config, fff-l3-config, ... wie bei deinem WebUI-Addon?

Sollten wir dann nicht auch configuregateway umbenennen duck

Dann wäre die meta-package "fff-layer3". Aber bei configuregateway willst du dann die Bezeichnung "gateway" beibehalten? Oder doch fff-layer3-config, fff-l3-config, ... wie bei deinem WebUI-Addon? Sollten wir dann nicht auch configuregateway umbenennen *duck*
ChristianD commented 2020-12-14 17:34:34 +01:00
Member
Copy Link
+		+fff-network

fff-babeld
fff-wireguard

Müssen mMn hier rein

``` + +fff-network ``` fff-babeld fff-wireguard Müssen mMn hier rein
adschm commented 2020-12-14 17:36:50 +01:00
Author
Owner
Copy Link
+		+fff-network

fff-babeld
fff-wireguard

Müssen mMn hier rein

Warum? Es gibt keine konkrete Abhängigkeit? Vielmehr hängen eher fff-babeld von fff-gw-config ab, weil die das gateway.d Skript enthalten. Diese Logik geht aber auch nicht, weil dann fff-wireless ein Problem wäre, das ein gateway.d Skript enthält, aber auch in fff-node verwendet wird. Daher war ich der Meinung, dass ein gateway.d Skript für sich keine Abhängigkeit von fff-gw-config begründet, da es ja nicht geparst werden muss.

> ``` > + +fff-network > ``` > > fff-babeld > fff-wireguard > > Müssen mMn hier rein Warum? Es gibt keine konkrete Abhängigkeit? Vielmehr hängen eher fff-babeld von fff-gw-config ab, weil die das gateway.d Skript enthalten. Diese Logik geht aber auch nicht, weil dann fff-wireless ein Problem wäre, das ein gateway.d Skript enthält, aber auch in fff-node verwendet wird. Daher war ich der Meinung, dass ein gateway.d Skript für sich keine Abhängigkeit von fff-gw-config begründet, da es ja nicht geparst werden _muss_.
ChristianD commented 2020-12-14 17:40:04 +01:00
Member
Copy Link

@adschm

Dann wäre die meta-package "fff-layer3". Aber bei configuregateway willst du dann die Bezeichnung "gateway" beibehalten? Oder doch fff-layer3-config, fff-l3-config, ... wie bei deinem WebUI-Addon?

Alles in layer3/l3 unbennen, der Begriff Gateway/gw sollte mMn nicht mehr auftauchen, nirgens mehr

Sollten wir dann nicht auch configuregateway umbenennen duck

Ja sollten wir auch aber vllt noch einen symlink belassen damit auch das gewohnte configuregateway noch funktioniert

@adschm >Dann wäre die meta-package "fff-layer3". Aber bei configuregateway willst du dann die Bezeichnung "gateway" beibehalten? Oder doch fff-layer3-config, fff-l3-config, ... wie bei deinem WebUI-Addon? > Alles in layer3/l3 unbennen, der Begriff Gateway/gw sollte mMn nicht mehr auftauchen, nirgens mehr >Sollten wir dann nicht auch configuregateway umbenennen *duck* Ja sollten wir auch aber vllt noch einen symlink belassen damit auch das gewohnte configuregateway noch funktioniert
ChristianD commented 2020-12-14 17:42:23 +01:00
Member
Copy Link

@adschm

+		+fff-network

fff-babeld
fff-wireguard

Müssen mMn hier rein

Warum? Es gibt keine konkrete Abhängigkeit? Vielmehr hängen eher fff-babeld von fff-gw-config ab, weil die das gateway.d Skript enthalten. Diese Logik geht aber auch nicht, weil dann fff-wireless ein Problem wäre, das ein gateway.d Skript enthält, aber auch in fff-node verwendet wird. Daher war ich der Meinung, dass ein gateway.d Skript für sich keine Abhängigkeit von fff-gw-config begründet, da es ja nicht geparst werden muss.

Ich glaube du hast Recht, ich hab da jetzt verkehrt herum gedacht. Die genannten Pakete brauchen eine Abhängigkeit hier hin

@adschm >> ``` >> + +fff-network >> ``` >> >> fff-babeld >> fff-wireguard >> >> Müssen mMn hier rein > >Warum? Es gibt keine konkrete Abhängigkeit? Vielmehr hängen eher fff-babeld von fff-gw-config ab, weil die das gateway.d Skript enthalten. Diese Logik geht aber auch nicht, weil dann fff-wireless ein Problem wäre, das ein gateway.d Skript enthält, aber auch in fff-node verwendet wird. Daher war ich der Meinung, dass ein gateway.d Skript für sich keine Abhängigkeit von fff-gw-config begründet, da es ja nicht geparst werden _muss_. Ich glaube du hast Recht, ich hab da jetzt verkehrt herum gedacht. Die genannten Pakete brauchen eine Abhängigkeit hier hin
adschm commented 2020-12-14 17:58:38 +01:00
Author
Owner
Copy Link

Alles in layer3/l3 unbennen, der Begriff Gateway/gw sollte mMn nicht mehr auftauchen, nirgens mehr

Mir fällt aus dem Stegreif nur kein guter neuer Name für configuregateway ein. Vorschläge?

Edit: Der naheliegende Kandidat wäre configure-layer3. Inhaltlich wäre das wohl gut, mir gefällt es rein ästhetisch nicht.

> Alles in layer3/l3 unbennen, der Begriff Gateway/gw sollte mMn nicht mehr auftauchen, nirgens mehr Mir fällt aus dem Stegreif nur kein guter neuer Name für configuregateway ein. Vorschläge? Edit: Der naheliegende Kandidat wäre `configure-layer3`. Inhaltlich wäre das wohl gut, mir gefällt es rein ästhetisch nicht.
ChristianD commented 2020-12-14 18:08:13 +01:00
Member
Copy Link

@adschm

Alles in layer3/l3 unbennen, der Begriff Gateway/gw sollte mMn nicht mehr auftauchen, nirgens mehr

Mir fällt aus dem Stegreif nur kein guter neuer Name für configuregateway ein. Vorschläge?

Edit: Der naheliegende Kandidat wäre configure-layer3. Inhaltlich wäre das wohl gut, mir gefällt es rein ästhetisch nicht.

Ich hätte dann configurelayer3 oder configurel3 im Angebot, den Bindestrich finde ich auch hässlich ;)

@adschm >> Alles in layer3/l3 unbennen, der Begriff Gateway/gw sollte mMn nicht mehr auftauchen, nirgens mehr > >Mir fällt aus dem Stegreif nur kein guter neuer Name für configuregateway ein. Vorschläge? > >Edit: Der naheliegende Kandidat wäre `configure-layer3`. Inhaltlich wäre das wohl gut, mir gefällt es rein ästhetisch nicht. Ich hätte dann configurelayer3 oder configurel3 im Angebot, den Bindestrich finde ich auch hässlich ;)
adschm commented 2020-12-14 18:23:13 +01:00
Author
Owner
Copy Link

Ich hätte dann configurelayer3 oder configurel3 im Angebot, den Bindestrich finde ich auch hässlich ;)

DerBindestrichunterstützthaltmassivdieLesbarkeit

> Ich hätte dann configurelayer3 oder configurel3 im Angebot, den Bindestrich finde ich auch hässlich ;) DerBindestrichunterstützthaltmassivdieLesbarkeit
ChristianD commented 2020-12-14 23:09:37 +01:00
Member
Copy Link

Ich hätte dann configurelayer3 oder configurel3 im Angebot, den Bindestrich finde ich auch hässlich ;)

DerBindestrichunterstützthaltmassivdieLesbarkeit

beizwei Wörterngeht dasaber geradenoch ;)

> > Ich hätte dann configurelayer3 oder configurel3 im Angebot, den Bindestrich finde ich auch hässlich ;) > > DerBindestrichunterstützthaltmassivdieLesbarkeit beizwei Wörterngeht dasaber geradenoch ;)
adschm force-pushed gatewayconfig from 03abc90989 to 0c01acd5a8 2020-12-15 12:51:22 +01:00 Compare
adschm commented 2020-12-15 12:51:50 +01:00
Author
Owner
Copy Link

@ChristianD Alles layer3 jetzt. Über ein Review würde ich freuen ...

@ChristianD Alles layer3 jetzt. Über ein Review würde ich freuen ...
adschm changed title from packages/fff: move config scripts from fff-gateway to fff-gw-config to packages/fff: move config to fff-layer3-config and use fff-layer3 2020-12-15 13:10:59 +01:00
adschm changed title from packages/fff: move config to fff-layer3-config and use fff-layer3 to packages/fff: split fff-gateway into fff-layer3-config and fff-layer3 2020-12-15 13:11:24 +01:00
ChristianD commented 2020-12-15 13:14:06 +01:00
Member
Copy Link

Nur noch kurz bevor ich auf Arbeit gehe:
Sollten so packages wie fff-babeld, fff-dhcp, fff-ra, fff-wireguard, etc. eine Abhängigkeit zu fff-layer3-config bekommen? Immerhin benötigen diese packages das fff-layer3-config

Nur noch kurz bevor ich auf Arbeit gehe: Sollten so packages wie fff-babeld, fff-dhcp, fff-ra, fff-wireguard, etc. eine Abhängigkeit zu fff-layer3-config bekommen? Immerhin benötigen diese packages das fff-layer3-config
ChristianD commented 2020-12-15 13:26:01 +01:00
Member
Copy Link

src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf → src/packages/fff/fff-layer3/files/etc/sysctl.d/60-fff-gateway.conf

Auch in 60-fff-layer3.conf unbenennen?

src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf → src/packages/fff/fff-layer3/files/etc/sysctl.d/60-fff-gateway.conf Auch in 60-fff-layer3.conf unbenennen?
adschm commented 2020-12-15 13:36:18 +01:00
Author
Owner
Copy Link

Nur noch kurz bevor ich auf Arbeit gehe:
Sollten so packages wie fff-babeld, fff-dhcp, fff-ra, fff-wireguard, etc. eine Abhängigkeit zu fff-layer3-config bekommen? Immerhin benötigen diese packages das fff-layer3-config

Das ist eine Ermessensfrage. Dem layer3.d/gateway.d Skript ist es erstmal egal, ob es ausgeführt wird oder nicht. Die primäre Frage ist, ob die Packages in ihrer Standardkonfiguration, also ohne Ausführen von configuregateway, in unserem Sinne korrekt funktionieren. Zum Beispiel kann man fff-babeld ja auch verwenden und manuell konfigurieren, ohne jemals ein configuregateway zu benutzen. Die gateway.d Datei wird zwar angeboten, aber muss nicht benutzt werden. In diesem Sinne besteht in meinen Augen eigentlich keine Abhängigkeit. Ähnliches gilt für fff-wireless, die ja auch mit der node-Firmware wunderbar funktioniert, ohne das man ein configuregateway hat.

Ich neige also tatsächlich eher dazu, hier keine Abhängigkeiten zu sehen.

src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf → src/packages/fff/fff-layer3/files/etc/sysctl.d/60-fff-gateway.conf

Auch in 60-fff-layer3.conf unbenennen?

Ja.

> Nur noch kurz bevor ich auf Arbeit gehe: > Sollten so packages wie fff-babeld, fff-dhcp, fff-ra, fff-wireguard, etc. eine Abhängigkeit zu fff-layer3-config bekommen? Immerhin benötigen diese packages das fff-layer3-config Das ist eine Ermessensfrage. Dem layer3.d/gateway.d Skript ist es erstmal egal, ob es ausgeführt wird oder nicht. Die primäre Frage ist, ob die Packages in ihrer Standardkonfiguration, also ohne Ausführen von configuregateway, in unserem Sinne korrekt funktionieren. Zum Beispiel kann man fff-babeld ja auch verwenden und manuell konfigurieren, ohne jemals ein configuregateway zu benutzen. Die gateway.d Datei wird zwar angeboten, aber muss nicht benutzt werden. In diesem Sinne besteht in meinen Augen eigentlich keine Abhängigkeit. Ähnliches gilt für fff-wireless, die ja auch mit der node-Firmware wunderbar funktioniert, ohne das man ein configuregateway hat. Ich neige also tatsächlich eher dazu, hier keine Abhängigkeiten zu sehen. > src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf → src/packages/fff/fff-layer3/files/etc/sysctl.d/60-fff-gateway.conf > > Auch in 60-fff-layer3.conf unbenennen? Ja.
ChristianD reviewed 2020-12-15 23:04:42 +01:00
src/packages/fff/fff-babeld/Makefile Outdated
@ -2,3 +2,3 @@
PKG_NAME:=fff-babeld
PKG_RELEASE:=2
PKG_RELEASE:=3
ChristianD commented 2020-12-15 23:04:42 +01:00
Member
Copy Link

https://git.freifunk-franken.de/freifunk-franken/firmware/pulls/18/files

ein Patch muss zuerst fertig gemacht werden

https://git.freifunk-franken.de/freifunk-franken/firmware/pulls/18/files ein Patch muss zuerst fertig gemacht werden
ChristianD commented 2020-12-15 23:10:41 +01:00
Member
Copy Link

Nur noch kurz bevor ich auf Arbeit gehe:
Sollten so packages wie fff-babeld, fff-dhcp, fff-ra, fff-wireguard, etc. eine Abhängigkeit zu fff-layer3-config bekommen? Immerhin benötigen diese packages das fff-layer3-config

Das ist eine Ermessensfrage. Dem layer3.d/gateway.d Skript ist es erstmal egal, ob es ausgeführt wird oder nicht. Die primäre Frage ist, ob die Packages in ihrer Standardkonfiguration, also ohne Ausführen von configuregateway, in unserem Sinne korrekt funktionieren. Zum Beispiel kann man fff-babeld ja auch verwenden und manuell konfigurieren, ohne jemals ein configuregateway zu benutzen. Die gateway.d Datei wird zwar angeboten, aber muss nicht benutzt werden. In diesem Sinne besteht in meinen Augen eigentlich keine Abhängigkeit. Ähnliches gilt für fff-wireless, die ja auch mit der node-Firmware wunderbar funktioniert, ohne das man ein configuregateway hat.

Ich neige also tatsächlich eher dazu, hier keine Abhängigkeiten zu sehen.

Kann ich mit der Erklärung so akzeptieren und verstehe nun den Gedankengang dahinter.

src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf → src/packages/fff/fff-layer3/files/etc/sysctl.d/60-fff-gateway.conf

Auch in 60-fff-layer3.conf unbenennen?

Ja.

Wenn das noch erledigt ist, sieht das Ding soweit gut aus.

> > Nur noch kurz bevor ich auf Arbeit gehe: > > Sollten so packages wie fff-babeld, fff-dhcp, fff-ra, fff-wireguard, etc. eine Abhängigkeit zu fff-layer3-config bekommen? Immerhin benötigen diese packages das fff-layer3-config > > Das ist eine Ermessensfrage. Dem layer3.d/gateway.d Skript ist es erstmal egal, ob es ausgeführt wird oder nicht. Die primäre Frage ist, ob die Packages in ihrer Standardkonfiguration, also ohne Ausführen von configuregateway, in unserem Sinne korrekt funktionieren. Zum Beispiel kann man fff-babeld ja auch verwenden und manuell konfigurieren, ohne jemals ein configuregateway zu benutzen. Die gateway.d Datei wird zwar angeboten, aber muss nicht benutzt werden. In diesem Sinne besteht in meinen Augen eigentlich keine Abhängigkeit. Ähnliches gilt für fff-wireless, die ja auch mit der node-Firmware wunderbar funktioniert, ohne das man ein configuregateway hat. > > Ich neige also tatsächlich eher dazu, hier keine Abhängigkeiten zu sehen. Kann ich mit der Erklärung so akzeptieren und verstehe nun den Gedankengang dahinter. > > > src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf → src/packages/fff/fff-layer3/files/etc/sysctl.d/60-fff-gateway.conf > > > > Auch in 60-fff-layer3.conf unbenennen? > > Ja. Wenn das noch erledigt ist, sieht das Ding soweit gut aus.
adschm force-pushed gatewayconfig from 0c01acd5a8 to 4c0b8d9edd 2020-12-15 23:21:43 +01:00 Compare
adschm commented 2020-12-15 23:22:02 +01:00
Author
Owner
Copy Link

So, extra für dich nochmal force-gepusht.

So, extra für dich nochmal force-gepusht.
ChristianD approved these changes 2020-12-15 23:56:47 +01:00
ChristianD left a comment
Member
Copy Link

Reviewed-by: Christian Dresel ffreifunk@dresel.systems

bitte beim applien aufpassen mit den PKG-release vom fff-babeld, aber das bekommst du schon hin ;)

Reviewed-by: Christian Dresel <ffreifunk@dresel.systems> bitte beim applien aufpassen mit den PKG-release vom fff-babeld, aber das bekommst du schon hin ;)
ChristianD approved these changes 2020-12-15 23:58:13 +01:00
ChristianD left a comment
Member
Copy Link

Reviewed-by: Christian Dresel <freifunk@dresel.systems>

bitte beim applien aufpassen mit den PKG-release vom fff-babeld, aber das bekommst du schon hin ;)

`Reviewed-by: Christian Dresel <freifunk@dresel.systems>` bitte beim applien aufpassen mit den PKG-release vom fff-babeld, aber das bekommst du schon hin ;)
adschm force-pushed gatewayconfig from 4c0b8d9edd to e40f754ac9 2020-12-16 18:03:45 +01:00 Compare
adschm commented 2020-12-16 18:04:01 +01:00
Author
Owner
Copy Link

Rebased.

Rebased.
adschm commented 2020-12-17 15:38:52 +01:00
Author
Owner
Copy Link

Merged.

Merged.
adschm closed this pull request 2020-12-17 15:38:52 +01:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
ChristianD
Labels
Clear labels   
RFC

   
RFT

   
WIP

   
blocked

   
bsp

touching bsp files or adding devices

  
bug

Something is not working

  
build/scripts/tools

touching buildscript or other tools

  
duplicate

This issue or pull request already exists

  
feature

New feature

  
fixed

Issue that got resolved

  
layer3

only for layer3 FW

  
mantis

Imported from mantis

  
more details required

Reported information is insufficient to debug the issue

  
needs changes

   
node

only for node FW

  
packages/fff

touching our packages

  
rejected

Rejected or won't fix

  
security

   
trivial

simple non-functional changes that are mostly matter of taste

  
upstream

touching upstream version, build or feed patches

No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: freifunk-franken/firmware#14
No description provided.
Delete Branch "adschm:gatewayconfig"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?