On Sat, Aug 06, 2016 at 01:17:37AM +0200, Julian Andres Klode wrote: > On Thu, Aug 04, 2016 at 06:08:26PM +0200, David Kalnischkies wrote: > > So, assuming we can agree on that this is in general a good idea, this > > would leave apt-transport-tor relatively empty (expect three symlinks, > > a depends on apt and a recommends on -https & tor) but perhaps this > > frees resources for a-t-t to gain an option to turn all sources into > > tor+http(s) [with debconf] or even .onion addresses, additional > > documentation… instead of diverting energy into maintaining an -https > > fork. > > > I'd prefer shipping the symlinks in apt itself, so it can be easily > used with an external tor proxy by just setting Acquire::tor::Proxy. Shipping tor+http in apt and tor+https in apt-transport-https would be possible of course, but I kinda hope that a separate -tor package shipping (tor+http) and recommending (a-t-https for tor+https) allows for better/easier integration: The switching of sources entries is one thing, documenting certain gotchas another: #749611 e.g. could be "solved" by using two (or more) different mirrors one with [lang=none] and the other with [targets=Translations] so that while you still leak the l10n you use, its at least via a different circuit (assuming my change) – you really want to "solve" this via .onion through, but not every repository in existence is available in this way. And just as an other example as that is a much more lowhanging fruit: I would like the -tor package to disable the http transport by default so a user can't forget to use tor+http for sources (added months later in the middle of the night) – I was thinking about http being an alias for tor+http if its installed, but that feels like a bit too much magic to be the default (especially considering that other tools extract URIs from apt and might or might not support/use tor). Haven't even tried it yet, but I would envision Dir::Bin::methods::http to be set to false to disable it – or in the opposite direction: Dir::Bin::methods::tor+http=http causing apt to call the http method with argv[0] == "tor+http" which would eliminate the need for an explicit symlink and would allow a user to get tor without installing tor/apt-transport-tor at the expense of loosing integration… mhh. /me wanders of trying to implement this. > apt-transport-tor also depends on tor ... I in the quote (and two bugreports) think it should be recommends for exactly this external tor case (also previous paragraph). So, while I started out with a "shallow it" approach I think it could be benefitial to keep it a separate package for now – assuming of course we can get someone interested in working on the integration/doc parts. Thinking into the blue here, but if we move the source package under the deity@ umbrella and deal with the technical aspects in src:apt that could be a nice package to contribute to from a newcomer/non-coder perspective… (yes, I know, I am prune to wishful thinking…). Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature