Questions about ptlib packaging

[Mark Purcell]

On Sunday 05 April 2009 03:57:30 Eugen Dedu wrote:
> I see that ptlib has been updated, thanks, Mark!  I have a few questions:
> - why experimental and not unstable?

Hi Eugen,

I have uploaded to experimental as it has been a while since upload and it 
needs to clear the NEW queue (pending) and be cleared by debian-release 
(done). Once it has cleared the NEW queue in experimental it doesn't have to 
do the same for a subsequent unstable release.

Experimental also gives us a sandbox to workout issues; building asterisk, 
opal, gnugk & yate-openh323. We could use unstable as a sandbox, but that 
effects a larger user base while we resolve transition issues.

Note that it still hasn't passed NEW so we are kinda still waiting.

> ekiga has been waiting to be
> uploaded in unstable for a too long time...
> - do you plan to upload it soon?

Yes.  I would like to get to the level of maturity where we are uploading 
every point release to unstable (and the occasional svn snapshot to 
experimental).  Once we pass NEW for experimental, I would like to wait a 
little while to see if there are any big issues from other users.  Then once 
any issues are scoped then we can upload to unstable.  Hopefully about a week.
 
> - why debian maintainers prefer creating another file (e.g.
> libptdev.install) instead of cp/mv?  For me, cp/mv are clearer: no need
> to know how *.install files work, no need to look into another file to
> see what is copied, and use one file instead of two

It comes from the Unix philosophy of using many small tools to do the job, 
rather than one large tool. In our case the use of the debhelper(1) to quote 
from the manpage:

       Debhelper is used to help you build a debian package. The philosophy
       behind debhelper is to provide a collection of small, simple, and
       easily understood tools that are used in debian/rules to automate
       various common aspects of building a package. This means less work for
       you, the packager.  It also, to some degree means that these tools can
       be changed if debian policy changes, and packages that use them will
       require only a rebuild to comply with the new policy.

This modularity I also view as a practical application of separation of 
concerns <http://en.wikipedia.org/wiki/Separation_of_concerns>.  In the debian 
case I see separation between debian/rules (the code) and *.install, *.docs, 
... (the data).

True you can build a debian/rules without any use of debhelper(1), but I would 
suggest that would create a very monolithic solution which maybe the original 
author can understand.  The team development environment for pkg-voip lends 
itself to the use of standard debian tools to break the monolithic solution 
into smaller easier to understand chucks. ptlib has always used some 
debhelper(1) tools witnessed by use of debian/; dirs, *.install & *.manpages. 
To easy development in team environment I encourage more use.

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20090405/93b9fc0a/attachment.pgp