We could maybe also just enable the apt-pinning for the rpi-gateway so it won’t get used for the other builds.
Maybe.
As per Re: Can a package pull a another package from another repository to be added? and Re: Can a package pull a another package from another repository to be added? APT pinning can break in very bad ways.
And offend Debian.
(And don’t forget all the hate you will get from me and other deity@l.d.o inhabitants because your users end up reporting bugs about APT)
Our past APT pinning instructions lead to breaking the system. ( Templates incorrectly think they're not connected to a Whonix gateway. - #25 by safasfasv )
Advantages:
- less code for download / reupload RPI firmware package
- less maintenance work for me for download / reupload RPI firmware package
Disadvantages:
- quality regression
- offending Debian
- possible issues on release upgrade
- other possible issues due to APT pinning (no specific example, hard to foresee)
I am inclined to say yes to APT pinning.
Any opinion @HulaHoop?
How would that technically work? Shipping file /etc/apt/sources.list.d/rpi.list as well as /etc/apt/preferences.d/ in some package?
deb http://http.debian.net/debian stretch-backports main contrib non-free
deb tor+http://vwakviie2ienjx6t.onion/debian stretch-backports main contrib non-free
(Plus comments.)
And then include instructions to remove that file before release upgrade of Whonix when upgrading to Debian 10 / buster in Whonix release upgrade instructions?