On 21 August 2016 at 22:36, David Kalnischkies <da...@kalnischkies.de> 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 haven't got a whole lot of feedback on this, but so far no NACKs so by
> recording this in a bugreport I hope to reach (again) out to people who
> might have different ideas on how to solve what basically is a modified
> embedded codecopy (of a Debian native tool none the less)

Hi!  I entirely missed your deity@ post, sorry.  Thanks for adding
socks support to apt.

I'm entirely supportive of merging a-t-t back somehow - I'd be happy
for the apt team to take over the package.

When I originally uploaded a-t-t as a forked https transport, it was
mainly intended as a quick proof-of-concept, as it did not look easy
at the time to add socks support directly to the http transport.  I
hope it played some small part in making it easier to use apt through
tor, and in getting official Debian onion mirrors set up.  But I'm not
attached to the code itself.

Kind regards,

-- 
Tim Retout <dioc...@debian.org>

Reply via email to