Re: Fwknop: Layout suggestions for a future implementation
Manoj Srivastava wrote: On Thu, Sep 03 2009, Franck Joncourt wrote: At a first glance there is no need to split it, and all of the binary packages could be created from one source package as you mentionned. However, for other distributions than Debian I do not know how their packaging stuff work. This is not an issue for any Debian derivatives; they all take the same underlying package infrastructure. Non derivative distributions will not use the Debian packaging, and thus splitting it in Debian will not help anyone. So, if this is questions the upstream is considering, you already have the answer: Looking at projects like mysql and dhcp, I would tend to say it is fine to have both the client and server applications bundled in the source package with the shared library. I think the project, and thus the tarball, should reflect the line of development; this is a single project, developed together, and thus the tarball should remain together, especially since this avoids the hassle of the different source tarballs gtting out of sync somewhere. Most distriutions have already figured out how to create multiple binary packages from a single source tarball, so this should not be a consideration. Thanks for your answer. Upstream is going to work with a single tarball ; There was a misunderstanding between tarballs and binary packages. At least, it is now clear :) Regards, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ signature.asc Description: OpenPGP digital signature
Re: Fwknop: Layout suggestions for a future implementation
Manoj Srivastava wrote: On Wed, Sep 02 2009, Franck Joncourt wrote: I have got one tarball from upstream which is separated in fwknop-client and fwknop-server. The programs are mainly implemented in perl. Upstream is now working on rewriting it in C. Thus we have now a brand new tarball available known as fwknop-c. This new tarball contains at the moment : - a shared library - libfko - the documentation of the shared library - an XS module FKO that allows fwknop-client/server to use the new libfko library. - the fwknop client written in C - later maybe a fwknop-c-server Therefore, I was thinking about such binary packages: - 1) a shared library libfko0 - 2) a devel package libfko0-dev - 3) a doc package libfko-doc - 4) a fwknop-c-client - 5) a fwknop-c-server - 6) a libspa-fko-perl module and I was suggesting to split the current fwknop-c tarball in three as following: - one for 1+2+3 - one for 4+5 - one for 6 To me it looks reasonable to split it. What do others think? Upstream is also insterested in hearing your opinions :) Please explain why it needs to be split? A single source package can create as many binary packages as are desired, so the splitting off the binary packages does not impose any requirements to split the source package. At a first glance there is no need to split it, and all of the binary packages could be created from one source package as you mentionned. However, for other distributions than Debian I do not know how their packaging stuff work. I thought interfaces to the shared library could be maintained through a different tarball. Therefore the xs module could have been added to CPAN. I mean, it would be like the libpcap library and its differents interfaces. Does it make sense? Looking at projects like mysql and dhcp, I would tend to say it is fine to have both the client and server applications bundled in the source package with the shared library. However, people start working on GUIs to send SPA packets to the current fwknop-server. Although the server and client side are the roots of the shared library (this one has been created to allow their rewrite in C), maybe the application could be put into another tarball as other applications would be. We are not to split the tarball or to gather everyting in the same tarball, but in the middle :) What is the wiser thing to do? Which layout to use to make it easy to maintain. Are there any problems which could be encountered by using one method rather than the other? This mail is intended to get your thoughts about the way the project should be laid. Regards, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ signature.asc Description: OpenPGP digital signature
Re: Fwknop: Layout suggestions for a future implementation
On Thu, Sep 03 2009, Franck Joncourt wrote: Manoj Srivastava wrote: On Wed, Sep 02 2009, Franck Joncourt wrote: I have got one tarball from upstream which is separated in fwknop-client and fwknop-server. The programs are mainly implemented in perl. Upstream is now working on rewriting it in C. Thus we have now a brand new tarball available known as fwknop-c. This new tarball contains at the moment : - a shared library - libfko - the documentation of the shared library - an XS module FKO that allows fwknop-client/server to use the new libfko library. - the fwknop client written in C - later maybe a fwknop-c-server Therefore, I was thinking about such binary packages: - 1) a shared library libfko0 - 2) a devel package libfko0-dev - 3) a doc package libfko-doc - 4) a fwknop-c-client - 5) a fwknop-c-server - 6) a libspa-fko-perl module and I was suggesting to split the current fwknop-c tarball in three as following: - one for 1+2+3 - one for 4+5 - one for 6 To me it looks reasonable to split it. What do others think? Upstream is also insterested in hearing your opinions :) Please explain why it needs to be split? A single source package can create as many binary packages as are desired, so the splitting off the binary packages does not impose any requirements to split the source package. At a first glance there is no need to split it, and all of the binary packages could be created from one source package as you mentionned. However, for other distributions than Debian I do not know how their packaging stuff work. This is not an issue for any Debian derivatives; they all take the same underlying package infrastructure. Non derivative distributions will not use the Debian packaging, and thus splitting it in Debian will not help anyone. So, if this is questions the upstream is considering, you already have the answer: Looking at projects like mysql and dhcp, I would tend to say it is fine to have both the client and server applications bundled in the source package with the shared library. I think the project, and thus the tarball, should reflect the line of development; this is a single project, developed together, and thus the tarball should remain together, especially since this avoids the hassle of the different source tarballs gtting out of sync somewhere. Most distriutions have already figured out how to create multiple binary packages from a single source tarball, so this should not be a consideration. manoj -- The more things change, the more they stay insane. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Fwknop: Layout suggestions for a future implementation
(Upstream is CCed, please keep it that way) PS: Mail previously sent to debian-mentor, but I did not get any answers, therefore I try on devel. Hi, I am the maintainer of fwknop: http://packages.qa.debian.org/f/fwknop.html The FireWall KNock OPerator implements an authorization scheme called Single Packet Authorization (SPA), based on Netfilter and libpcap. Its main application is to protect services such as OpenSSH with an additional layer of security in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) much more difficult. I have got one tarball from upstream which is separated in fwknop-client and fwknop-server. The programs are mainly implemented in perl. Upstream is now working on rewriting it in C. Thus we have now a brand new tarball available known as fwknop-c. This new tarball contains at the moment : - a shared library - libfko - the documentation of the shared library - an XS module FKO that allows fwknop-client/server to use the new libfko library. - the fwknop client written in C - later maybe a fwknop-c-server Therefore, I was thinking about such binary packages: - 1) a shared library libfko0 - 2) a devel package libfko0-dev - 3) a doc package libfko-doc - 4) a fwknop-c-client - 5) a fwknop-c-server - 6) a libspa-fko-perl module and I was suggesting to split the current fwknop-c tarball in three as following: - one for 1+2+3 - one for 4+5 - one for 6 To me it looks reasonable to split it. What do others think? Upstream is also insterested in hearing your opinions :) Regards, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: Fwknop: Layout suggestions for a future implementation
On Wed, Sep 02 2009, Franck Joncourt wrote: I have got one tarball from upstream which is separated in fwknop-client and fwknop-server. The programs are mainly implemented in perl. Upstream is now working on rewriting it in C. Thus we have now a brand new tarball available known as fwknop-c. This new tarball contains at the moment : - a shared library - libfko - the documentation of the shared library - an XS module FKO that allows fwknop-client/server to use the new libfko library. - the fwknop client written in C - later maybe a fwknop-c-server Therefore, I was thinking about such binary packages: - 1) a shared library libfko0 - 2) a devel package libfko0-dev - 3) a doc package libfko-doc - 4) a fwknop-c-client - 5) a fwknop-c-server - 6) a libspa-fko-perl module and I was suggesting to split the current fwknop-c tarball in three as following: - one for 1+2+3 - one for 4+5 - one for 6 To me it looks reasonable to split it. What do others think? Upstream is also insterested in hearing your opinions :) Please explain why it needs to be split? A single source package can create as many binary packages as are desired, so the splitting off the binary packages does not impose any requirements to split the source package. manoj -- Never be afraid to tell the world who you are. Anonymous Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
