adding a binary package to pd-cyclone

[Jonas Smedegaard]

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.


>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20101231/76c5562b/attachment.pgp>