adding a binary package to pd-cyclone

[Hans-Christoph Steiner]

On Dec 31, 2010, at 8:11 AM, Jonas Smedegaard wrote:

> On Fri, Dec 31, 2010 at 12:51:47AM -0500, Hans-Christoph Steiner  
> wrote:
>> On Thu, 2010-12-30 at 00:53 +0100, Jonas Smedegaard wrote:
>>> On Wed, Dec 29, 2010 at 08:14:57PM -0300, Felipe Sateler wrote:
>>> >You edited debian/control, but Jonas added debian/control.in for  
>>> >build-dependencies autogeneration. If you disagree about the use  
>>> of >debian/control.in, we should disable it. If not, we should use  
>>> it. >But having it and not using it does not seem a sane option.
>>>
>>> I suggest we only drop the control.in if noone use the .in file or  
>>> it annoys someone.
>>>
>>> I see no big problem in some of us editing the control file  
>>> directly - the nuissence of sync'ing changes there to the .in file  
>>> is shadowed by the benefit of dependency semi-autoresolving IMO.
>>>
>>> (please do edit the .in file rather than the control file if you  
>>> want to help minimize work for everyone, though)
>>
>> Ok, I hope its alright with everyone, I removed the control.in.  I  
>> can see using automatic build-depends generation on a package with  
>> complex Build-Depends, but this one is really simple, and I think  
>> the Build-Depends will rarely change, if ever.
>
> If you mean to say that the control.in annoys you, then fine.
>
> If, on the other hand, you mean to say that you guess noone use  
> the .in file then you're wrong: I use it (as long as noone is  
> annoyed by it).
>
> Currently @cdbs@ resolves to "cdbs, debhelper (>= 6), dh-buildinfo".
>
> As an example, if at some point debhelper compat level is bumped to  
> 7, I bet manual build-dependency handling would be to just tighten  
> to "debhelper (>= 7)" but that is wrong - cdbs needs to be tightened  
> too due to a bug in early implementations of debhelper 7 support in  
> CDBS, and also (still in dispute, though - Joy disagrees with this!)  
> build-dependency on debhelper itself is tightened further than just  
> "7" as well, because not all of the core debhelper 7 features was  
> implemented initially.

For the record, I'm not saying that no one uses the file, or that the  
automatic Build-Depends handling isn't useful. I'm saying I think in  
this package, the benefits of the control.in are smaller than the  
disadvantages.

.hc



>> From my experience, build products should not be in git (i.e. the  
>> 'control' file generated using 'control.in').  Since that doesn't  
>> seem possible for 'control', I think we'll be better off by  
>> simplifying to a static 'control'.
>
> I disagree. Some files make sense only to autogenerate by the  
> respective code developers, and then (normally) shipped with the  
> code and treated as source by users of the code.  Examples of this  
> is Makefile files (when automake is used), Makefile.in files and  
> configure (when autoconf is used) and debian/control (when CDBS  
> dependency-resolving is used).
>
> For autotools it is possible to help distinguish between "user" and  
> "maintainer" modes of operation with an optional configure flag -- 
> maintainer-mode, and similarly CDBS has DEB_MAINTAINER_MODE.
>
>
> - Jonas
>
> -- 
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
> [x] quote me freely  [ ] ask before reusing  [ ] keep private
> _______________________________________________
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers




----------------------------------------------------------------------------

All mankind is of one author, and is one volume; when one man dies,  
one chapter is not torn out of the book, but translated into a better  
language; and every chapter must be so translated.... -John Donne