[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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/

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: