[tor-bugs] #9668 [Flashproxy]: restructure flashproxy source tree

[Tor Bug Tracker & Wiki]

#9668: restructure flashproxy source tree
----------------------------+-----------------
     Reporter:  infinity0   |      Owner:  dcf
         Type:  defect      |     Status:  new
     Priority:  normal      |  Milestone:
    Component:  Flashproxy  |    Version:
   Resolution:              |   Keywords:
Actual Points:              |  Parent ID:
       Points:              |
----------------------------+-----------------

Comment (by dcf):

 Replying to [comment:6 infinity0]:
 > Continuing from [comment:8:ticket:6810]:
 >
 > Let me also explain the packaging model. Currently, the top-level
 Makefile has two *binary* distribution targets, a python-source and a
 py2exe zipball. (We call the python-source a "binary" package even though
 it's source-code python, because the intention is to run it directly,
 there is no "install" process, and you don't provide any Makefiles or
 tests.)

 You are correct, `make dist` is totally a binary package. It's what ends
 up in the PT TBB, for example. (Just as with obfsproxy we do `setup.py
 build` before copying into the PT TBB, though we could probably get away
 with just copying straight from the source directory.)

 > OTOH for Debian (and good FOSS practise) I am building source packages,
 which include tests and build scripts. Everything is in one source repo at
 the moment, but I am doing source packaging on subfolders to make it
 easier to split the repo later, which you were vaguely talking about
 doing.

 Maybe I misunderstand you. Isn't it typical that many binary packages are
 built from one source package? For example, when I `apt-get source
 openssh-server`, it informs me that it is actually downloading the source
 package "openssh".
 {{{
 $ apt-get source openssh-server
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 Picking 'openssh' as source package instead of 'openssh-server'
 NOTICE: 'openssh' packaging is maintained in the 'Bzr' version control
 system at:
 http://anonscm.debian.org/bzr/pkg-ssh/openssh/trunk
 }}}
 I expected that flashproxy packaging would work the same way: binary
 packages "flashproxy-client" and "flashproxy-facilitator", say, built from
 a single source package "flashproxy". I don't understand the need to have
 multiple source packages, each made from a subdirectory.

 As for splitting the repo, let's assume that flashproxy-client and
 facilitator will continue to be together, because they will share
 libraries. websocket-transport will be completely separate--I don't want
 it even referred to in the top-level makefile.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9668#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online