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

Martin-Eric Racine q-funk@iki.fi
Fri Jul 15 04:27:27 UTC 2005

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

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,=
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=
spanked by the powers that be, to ensure that they will never again reject=
a package simply because it uses a CDBS feature he disagrees with.

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

Martin-Eric Racine

---------- 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=
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=
       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, =
        to reupload an unfixed version and hope that another one processing=
        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=
*before* you upload it again. Thanks.

bye Joerg


If you don't understand why your files were rejected, or if the
override file requires editing, reply to this email.

More information about the Build-common-hackers mailing list