Questions about ptlib packaging

[Eugen Dedu]

Mark Purcell wrote:
> 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.

Hi,

Any news?

Eugen