[tor-dev] Thoughts on simplified packaging

grarpamp grarpamp at gmail.com
Wed Jun 15 06:05:44 UTC 2011

On workload and stuff...

> the idea we had at the 2010 Potsdam meeting where we had primary
> and secondary developers for each product.

There is Tor core (ported to various platforms). This is code and
docs. This is what matters. It is not config or packaging.

Above and beyond that, if there is a demand for it, why not introduce
a secondary level of suitably trusted enthusiasts to develop and
manage all the various modes of operation. Officially disclaim it
appropriately as an unofficial vaporware framework, wikify it, put
a couple public developer packaging boxes online and see what

Also, you could easily publish just a set of torrc's tailored to
various purposes. Or even create an online config generator with
various feature checkboxes.

Also, a visible and similarly adjunct FAQ and docs team for those
of us who ask silly questions like myself :) And I guess, a searchable
and downloadable email archive. It could save some time of some of
the people who reply to 'Subject: Please help' people.

TBB... Tor Browser Bundle... sure, this is useful. But a pain for
each platform. I would punt it to the secondary team. Then focus
on one, Torify everything, bootable Unix platform.

> 1. If a user wants to run both a tor-client and >
tor-(relay|exit-relay|bridge) on the same host, we run into port

Goes to config generator or posted configs. Plus to some degree you
get config modernization out there in Torland for free.

> 3. The conversion from legacy to new packaging could be a mess.

I've never had a problem being forced to accept breakage of backward
compatibility. Then again, I'm not Joe user. Still, assuming there
is constant new user influx, such breakage won't lead to lost
capacity. That's what major.minor.rev revision numbering is for.

> 5. The *BSD ports system ... for non-exit, exit, and bridge relay.

Really? Users who can deal with ports can certainly deal with a
little Tor config.

> Conclusion

I've no objection to flag days that result in good long term gains.

More information about the tor-dev mailing list