Upgrades und alten config files?

Hey, wie macht ihr das so mit upgrades?
Die Berliner haben immer migration files geschrieben. Ich bin damit aber sehr unglücklich und hätte lieber immer komplett alle neuen configs und die user changes nochmal kurz applied.

Das wäre eigentlich gar nicht so schwer, gäbe es nicht die uci-defaults (wo nicht nur uci Befehle drinne sind), die ich gerne ausschließen würde. Ich bräuchte sozusagen eine Copy des Zustands nach einem initialen boot.

Openwrt hat dafür doch eigentlich ein ziemlich robustes Verfahren, das live zusammenzupacken vor dem Flashen und dann wieder einzuspielen.

Setzt natürlich voraus, dass man im UCI-Konzept geblieben ist und die Config mehr oder minder komplett in /etc bleibt.

Ansonsten liegt bei Gluon analog zu einem init.d-directory ein update-directory voller hook-scripts, die nach einem Upgrade (oder auch einem web-ui-reconfigure) aufgerufen werden.
Die ziehen dann Dinge „gerade“, die aus den UCI-Settings abgeleitet werden, z.B. wenn’s da bei den Radios nach Verstellen von Kanälen noch was zu beachten gibt. Oder schlicht wenn es im Rahmen des Updates breaking-changes zu migrieren gibt (z.B. Wechsel des crondemons, oder vpn-protokolls)

Jein. Du bekommst halt nur dein altes Config File wieder? Wenn zwischendurch das Config-File von einem Programm wichtige Changes hatte, dann hast du trotzdem das alte weiter?

Mir scheint es halt irgendwie einfacher, die User Veränderungen rauszunehmen und die wieder drauf zu tun, als die User-Änderungen + „Upstream Config Veränderungen“.

Danke. Schade das es so etwas noch nicht gibt.

Dann habe ich mich wohl nicht deutlich genug ausgedrückt.

Welche Information fehlt Dir? Nur weil das AUCH nach einem Webconfig-Change durchlaufen wird, heisst es nicht, dass es sich nicht auch um breaking changes bei Versionsmigration kümmert.

So mal als Beispiel (Ja, da sind auch community-packages dabei)
Da die schon „lua-shelldieted“ sind, sollte schon die Größe der scripte darauf hindeuten, dass da etwas gluelogic drin wohnt.

/lib/gluon/upgrade# ls -l
    168  001-upgrade
    513  005-site-domain
   2074  010-primary-mac
    866  020-interfaces
    343  030-system
    278  100-authorized-keys
    292  100-core-reset-sysctl
    176  100-lock-password
   1096  110-network
   1969  110-preserve-wireless-channels
    231  120-ntp-servers
   1554  140-firewall-rules
    294  150-poe-passthrough
    417  180-outdoors
   3667  200-wireless
   2131  209-eulenfunk-ch13to9
   6979  210-gluon-txpower-fix
    632  210-interface-wan
   1039  220-interface-lan
   1262  300-gluon-client-bridge-network
    315  300-setup-mode
    790  310-gluon-client-bridge-local-node
    739  310-gluon-mesh-batman-adv-mesh
    304  310-setup-mode-migrate
    623  320-gluon-client-bridge-wireless
    862  320-gluon-mesh-batman-adv-client-bridge
    481  320-setup-ifname
    207  330-gluon-mesh-batman-adv-mac-addresses
    567  400-mesh-vpn-tunneldigger
    448  400-neighbour-info-firewall
   1100  400-respondd-firewall
    978  500-autoupdater
   1620  500-mesh-vpn
    151  500-node-info-system
   1195  500-opkg
     73  500-radvd-remove-user
    625  500-ssid-changer
    557  500-status-page
    244  510-node-info-role
    333  520-node-info-whitespace-fix
    440  800-migrate-batadv
    810  820-dns-config
    115  888-button-bind
    277  900-ath9kblackout
    883  910-eulenfunk-migrate-updatebranch
     27  998-commit
    215  999-move-banner
    139  999-version

Hmm? OpenWrt sichert die Dateien, die in einer Liste aufgeführt sind, und spielt sie nach einem Update zurück (außer, man untersagt genau dies). Dein Fall kann also nicht auftreten?