[Build-common-hackers] usage of CDBS' control.in feature resulting in packages rejected by
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
[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.
---------- Forwarded message ----------
Date: Wed, 13 Jul 2005 19:02:38 -0400
From: Joerg Jaspert <firstname.lastname@example.org>
To: "[utf-8] Martin-=C9ric Racine" <email@example.com>
Cc: Debian Installer <firstname.lastname@example.org>
Subject: gaim-irchelper_0.11-1_i386.changes REJECTED
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=
course always free to answer to this mail and state your position, =
to reupload an unfixed version and hope that another one processing=
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.
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