On Fri, Jun 03, 2005 at 12:08:01AM +0200, Joerg Jaspert wrote: > > Im talking about the "Update Build-Depends on the fly" thing and the bad > things that it produces. > > Sorry, but Packages with such autogenerated build-dependencies should > not go in our archive, for various reasons, the biggest one is: > > - Modifying them on the fly can mean that they change without you noticing > it. This is not bad for the actual built you do, but now think about later > builds. Our autobuilders will get the changed Build-Dependencies and then > may built a different thing. > Or think about NMUs (eg. for RC fixes and stuff) or in worst case even > security updates.
I am playing with the idea of having cdbs ensuring that the human provided dependencies are enough. I mean, if cdbs various part say that we need this: > 1: debhelper (>=4.2.0), cdbs (>=0.4.23-1.1), build-essential, > debhelper (>=4.1.0), quilt, patchutils (>=0.2.25), > cdbs (>=0.4.27-1), python-dev then make sure that the build dependencies hand-written in the control file ensure at least debhelper (>=4.2.0), cdbs (>=0.4.27-1), quilt, patchutils (>=0.2.25), python-dev Ie, that the set of human provided build-dependencies encompass the script demanded ones. Would it be ok for you to stop the compilation process if it's not the case (ie, if the human forgot one build-dep, according to the scripts), or would you consider this as just another form of the pure evil you are talking in your mail? Anyway, I'm struggling with implementations issue here and don't plan to do anything before a while. Of course, I could do a little perl script somewhere under /usr/lib doing the verification, but I was kind of wondering if such thing already exists in dpkg or apt or not... Bye, Mt.
signature.asc
Description: Digital signature
