[tor-bugs] #7842 [Tor bundles/installation]: make a graphical TBB installer (extractor)
Tor Bug Tracker & Wiki
blackhole at torproject.org
Sat Mar 2 10:52:27 UTC 2013
#7842: make a graphical TBB installer (extractor)
--------------------------------------+-------------------------------------
Reporter: proper | Owner: mo
Type: enhancement | Status: assigned
Priority: normal | Milestone:
Component: Tor bundles/installation | Version:
Keywords: tbb-usability | Parent:
Points: | Actualpoints:
--------------------------------------+-------------------------------------
Comment(by mo):
If this "one-click wrapper" is really the way we want to go, some more
things to consider: We can't really put the files anywhere and just leave
them lying around, as this is against the "zero footprint". Besides, it is
a very bad custom to just leave files lying around somewhere. So, unless
we make it clear to the user where we actually put the files (by giving
her shortcuts or guide through the extraction process), the only way that
is left towards a "one-click wrapper" would be to extract all files every
time (maybe to a ramdisk), and zip them back up afterwards (to keep state
files and customizations).
Since we also want people to be able to upgrade and keep their changes,
and we can't store where we actually put the last installation ("zero
footprint"), we would have to ask the user if she wanted to import an old
TBB profile at least on first start of the wrapper, and make her point us
at the previous wrapper (and hope she did not just replace it already,
thinking we keep settings stored somewhere else like a regular
application). In general, for a working update process, we would need the
ability to also remove files in the wrapper, because, currently, all we do
is put more stuff into the TBB directory. Which is bad when we plan to
drop stuff, like Vidalia or an extension.
Replying to [comment:8 mikeperry]:
> I don't think we need to warn about overwriting an existing Tor Browser.
That should work in the future. It simply didn't work this time because of
the major changes from FF10->FF17. We may end up with similar issues
during the switch from FF17-FF24, but normally it should be fine to
upgrade in this way, and this is how we intend to make the updater work.
It will happen again. The wrapper/installer should at least be prepared
for situations like that, because likely the build engineer will not have
enough time to do it then. I don't see how overwriting currently "works",
given it does overwrite at least custom torrc's.
A reasonable wrapper/installer that does not need to be changed too often
knows about configuration files (torrc and the Firefox profile, anything
else?), copies them to a temporary location (ideally a ramdisk), deletes
the previous installation, extracts, and copies back the config files.
This will not work if we change torrc settings again.
If the build engineer does not have enough time to figure out details, and
wants to indicate that upgrading is harder than the regular upgrade
process (currently: overwriting), it should be a simple switch to warn or
even block extraction to an existing directory.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7842#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list