from the output of opkg --help you can see this information:
Use <dest_name> as the the root directory for package installation, removal, upgrading. <dest_name> should be a defined dest name from the configuration file, (but can also be a directory name in a pinch).
So, I edited my /etc/opkg.conf adding a dest name called opkg_test for /tmp folder; My etc/opkg.conf now is:
dest root /
dest ram /tmp
dest opkg_test /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
option check_signature 1
Then, I've copied a package (transmission-web_2.92+git-4_mipsel_24kc.ipk) in /tmp/ to make a test, and launched opkg this way:
@Douglas-Kryder all great information, thank you. Your guess of a new wifi driver release seems realistic. If it doesn't arrive by July (which would be nearly 1 year late) then it probably won't ever come. I'll start testing the official lede builds with Onion packages and report back my findings.
Looks like this is the most recent thread on GPIO Interrupts. What's the current status on GPIO interrupt support on the Omega2?
what are the typical latencies associated with the sysfs method?
are there any advantages for the kmod-gpio-irq path?
if so, is there a reliable way to use kmod-gpio-irq on the Omega2 or is it likely to end in the dead-ends reported in this thread?
@Ismas the architecture (target) in menuconfig is called "Ralink RT288x/RT3xxx", under which you find a subtarget "MT7688 based boards" and finally the Omega2 profiles.
Before starting to dig through Linux sources for these SoCs I hadn't realized how difficult it is to relate chip names to their architectures and drivers. There's little logic in it, but a lot of history.
How would one be able to guess the MediaTek 7688 goes under the "Ralink" architecture? Of course, once you know that Ralink was once a company that made MIPS based SoCs, and was aquired by MediaTek in 2011, it makes sense.
Still, support for the MT7688 can go by any names with "ralink", "rt", "mt76" "7621" and probably quite a few others. Comments in drivers often refer to subsystems that probably once were separate chips and thus had a completely different number. And all this being in the mostly proprietary SoC world (few proper datasheets) makes it hard to figure out what belongs where. So it took a while for a beginner like me to even start connecting dots... ;-)