[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9668 [Flashproxy]: restructure flashproxy source tree
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs