Such an implementation would suffer from dpkg interactive conflict resolution dialog. Non-ideal but not a blocker. dpkg interactive conflict resolution dialog would probably mean “advanced users only”.
Also quiet hacky still… Idea maybe it would lead somewhere…
If some config is set (by creating a file or setting in /etc) the repository onionizer (working name until a better is invented) a dpkg trigger could redo any onionizing if file /etc/sources.list or any file in folder /etc/sources.list.d is modified by APT?
dpkg triggers are only working for files which are managed by any packages.
Managed by APT (because shipped by a package):
/etc/apt/debian.list/etc/apt/qubes-r4.list
Not managed by APT (created by script):
/etc/apt/sources.list- maybe OK since empty by default in Kicksecure / Whonix/etc/apt/sources.list.d/derivative.list- maybe OK because repository-dist could have native--tor-onionsupport
An even more hacky way would be to use inotifywait (some examples in Whonix source code). Whenever an APT sources list file would be modified (by package, script or user), any supported (known by repository onionizer) clearnet domain names would be changed back to clearnet.
In any case, for transparency and usability, if modifications are done by repository onionizer, then repository onionizer should add a comment (non-duplicating, not adding same comment over and over again)) to the file stating that it was done, link to documentation so the user can figure out what happened and how to disable this feature?
The repository onionizer might fit into the already existing repository-dist package?
I don’t know real world examples yet but it is conceivable to get onion combined with https repositories in the future. I.e. tor+https://deb.onion.onion. If you don’t mind, while scripting, could you please consider this future possibility?
That style to use sed looks easy to read, nice and clean to me.