Open matteodelabre opened 3 years ago
We may also want to rebuild Entware packages from source, for example to make sure that they match our toolchain. To avoid having to rewrite their recipes to our format, we could make our tooling support the OpenWrt recipe format (see toltec-dev/build#18).
Wouldn't we override their packages by having our archs (rmall, rm1 and rm2) have higher priorities than theirs? Or is that rule secondary to a higher version?
* Updates coming from Entware are immediately available to all users without giving us time to vet that they properly work with our packages. See for example the recent rename of `wget` to `wget-ssl`.
We could always host a snapshot of the repo for stable and update it with the normal process we use for toltec as another option.
Entware's website (bin.entware.net) is blocked/filtered in my region, this results in toltec failing to bootstrap.
Current Toltec installs use a dual-source configuration: opkg fetches packages both from https://bin.entware.net/armv7sf-k3.2/ and https://toltec-dev.org/stable/. This has the advantage of saving bandwidth costs on our server, but has several drawbacks:
wget
towget-ssl
.wireguard-tools
in Entware (#285). For another example, Entware already has some Qt packages (qt5-core, qt5-network, qt5-xml) that are stuck on 5.14.2 (#212).To address those limitations, we may want to re-host packages from Entware directly on Toltec. We would be free to pin some older package versions if necessary, or filter out some packages that are known to break on reMarkable or that we wish to replace with our own.