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.


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


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

pkg-multimedia-maintainers mailing list

Reply via email to