Vlákno názorů k článku OpenWrt přechází z opkg na balíčky apk – jaký je v tom vlastně rozdíl? od Peter Lištiak - Vítam zmenu na apk, mrzí ma, že to...

Vítam zmenu na apk, mrzí ma, že to už nestihli dať do 24.10. Po prečítaní tohto článku mi však napadá, prečo radšej nezobrali opkg z OpenEmbedded? Predsalen by bolo nutné meniť menej vecí, lebo skoro všetko by malo fungovať ako predtým, len by sa pridala nová funkcionalita. Alebo mi niečo uniká?

Zde asi záleží na tom, jak moc opkg z OpenEmbeded narostl a co umí navíc.

Použití verze z OpenEmbedded by vyřešilo některé problémy a přidalo trochu nové funkcionality, ale apk je pořád o hodně dál. Hlavně co se obecného přístupu ke správě balíčků týče - solver, world a podobně.

jo - ted presne jsem dosal jeden cisty OpenWRT system do inkonzistentního stavu... apk by to resilo, takze nastesti to je virtualizovane takze snapshot/backup ... turris ma tohle nad OpenWRT dobre vyresene v zakladu
jsem zvedavy na dalsi vyvoj TOS a zacleneni apk...

Možno by bolo riešením aj adopcia od turrisu ... znova by to asi bolo menej náročné na vývoj ako prejsť komplet na apk. Otázka je, či ľudia z OpenWrt o turrise vedia :)

Já bych v té migraci neviděl až takový problém. První a nejdůležitější krok je zprovoznit APK samotné, další krok je začít balit vše duálně - tak, aby byly soubory uvnitř balíčků identické. Další krok je „přeinstalovat“ vše pomocí APK - tedy vybudovat world.

Tolik teorie.

V praxi bych to viděl na dualstack - staré instalace budou mít k dispozici opkg, nové pojedou přes apk. Pak se jednou řekne, že opkg už nebude dostávat nové balíky.

Stejně je celkový upgrade pomocí opkg peklo, takže ve většině případů to znamená přeflashovat firmware. Pak je to jen o migraci nástrojů, kde se to nejspíš dá zajistit wrapperem pro zpětnou kompatibilitu.

Ono to aktualne je jako volba pri buildu OpenWrt stromu. Clovek si muze zvolit, jestli chce produkovat opkg nebo apk balicky. Balicky se buildi stejne, metadata se vygenerujou z predpisu a obsah balicku - to co se rozbaluje na rootfs - je taky stejny. Jen ty metadata se zapisou v jinym formatu a cely se to musi trochu jinak zabalit. A nove se musi podepisovat kazdej balicek zvlast, zatimco do ted nemusel byt kazdy produkcni klic pri buildu dostupny. 24.10 ma opkg, ale snapshoty uz se buildej s apk.

O Turrisu vedi, ale nas updater tech zavislosti ma jeste vic, nez apk :-)

pro zajimavost, jak? upgradem vsech balicku?

protoze me se za roky to nepodarilo, a to nevychazim z cisteho img, ale z imagebuilder s upravama treba:
- vychozi shell nahrazen za bash
- dropbear nahrazen za openssh
- mbedtls nahrazene za openssl
- pridane mc a byobu ktere si dotahne kus pythonu
- fwknopd + kvuli kompatibilite s nim iptables-nft
- pridan wireguard
- pridane coreutils

nasledne to pak treba rok aktualizuju stylem:
opkg list-upgradable | cut -f1 -d' ' | xargs opkg upgrade

To mám podobně:
opkg update
opkg list-upgradable|awk '{print "opkg upgrade " $1}'|sh

tohle mne zajima
bash, openssh, openssl - v cem to ma vyhodu?

- bash - primarne kvuli zvyku, kdy vsude na nb/pc/server mam bash a scripty pisou vsude pro bash :-)

- openssh - dropbear nema sftp a i kdyz by asi stacilo jen k dropbear pridat openssh-sftp-server, nahradil sem i ten dropbear, take castecne o zvyku

- openssl - jestli si dobre pamatuju v 23.05 mbedtls bylo ve verzi co melo nejake omezeni a "prepnuti" na openssl byl (polo?)oficialni workaround :)

- byobu - opet o zvyku a kvuli prakticnosti, kdy ssh spojeni kamkoliv nahazuju rovnou s byobu, nejen kvuli navratu k "rozdelanemu" priste, ale i dlazdicovani/lis­tovani

edit: k byobu mam pridan tmux-resurrect, takze i po rebootu obnovim ulozenou "byobu" session :)

12. 12. 2024, 17:05 editováno autorem komentáře