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 <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: