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@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
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
