[Build-common-hackers] usage of CDBS' control.in feature resulting in packages rejected by FTP Master

[Martin-Eric Racine]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323328-1269782140-1121401647=:23370
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

[not subscribed to the CDBS list; please CC reply to me]

See forwarded message below.

It would be strongly appreciated that the CDBS maintainers get a binding=20
statement from the powers that be as to whether modifying the build-deps=20
using the CDBS control.in trick indeed is something against policy or not.

1) If it is, fine, let's get the Debian Policy to explicitely state that,=
=20
then remove the CDBS feature in question and move along.

2) If there's nothing such in Policy, let's make the concerned FTP Master=
=20
spanked by the powers that be, to ensure that they will never again reject=
=20
a package simply because it uses a CDBS feature he disagrees with.

Swift action on your part to resolve this issue would be appreciated.

Thanks!
--=20
Martin-Eric Racine
http://q-funk.iki.fi

---------- Forwarded message ----------
Date: Wed, 13 Jul 2005 19:02:38 -0400
From: Joerg Jaspert <ftpmaster@debian.org>
To: "[utf-8] Martin-=C9ric Racine" <q-funk@iki.fi>
Cc: Debian Installer <installer@ftp-master.debian.org>
Subject: gaim-irchelper_0.11-1_i386.changes REJECTED

Hi Maintainer,

While checking your package in NEW I found that it has the cdbs "Play with
my debian/control in a bad way" option turned on, and thus modifies
Build-Dependencies on the fly.

Sorry, but we must reject such packages. Please read on:

- Modifying them on the fly can mean that they change without you noticing
   it. This is not a problem for the build you do, but now consider later
   builds: our autobuilders will get the changed build-dependencies and may
   then build a substantially different package.
   NMUs (e.g. for release-critical fixes) or at worst even security updates
   also become much more fragile when this option is enabled.

- If you need help from a script to set Build-Dependencies or similar,
   please take another approach:
   Add another target in your debian/rules, that is *never* called
   automatically during the build process, but only if you run it with
   'debian/rules <target>' explicitly so that you have an opportunity to
   review the changes it makes.

The only exception from modifying something in the first paragraph of
debian/control is the Uploaders field, as it would be difficult for some bi=
g
group-maintained packages to do that by hand.

You may want to follow bug #311724, which is about exactly this issue.

Note: I haven't looked much deeper into your package, but assuming it is
       otherwise error-free it may be approved; so feel free to upload a
       fixed version whenever you want. (Of course, if it violates policy o=
r
       similar, I will contact you again and let you fix it. This isn't a
       wildcard. :) ).

Note2: This is *MY* opinion/position on this matter. If you disagree you ar=
e of
        course always free to answer to this mail and state your position, =
or
        to reupload an unfixed version and hope that another one processing=
 NEW
        accepts this.

Oh, while you are changing the debian/ for this, *please* look into the
debian/control you then take, please fix the broken Build-Depends line it g=
enerated
*before* you upload it again. Thanks.

--
bye Joerg




=3D=3D=3D

If you don't understand why your files were rejected, or if the
override file requires editing, reply to this email.
--8323328-1269782140-1121401647=:23370--