On Wed, Aug 03, 2011 at 02:24:16PM +0100, Tim Retout wrote: > On 2 August 2011 13:24, Ricardo Mones <mones@debian.org> wrote: > > From the dialog on the bug seems only Build-Depends are adjusted by the > > packages existing in the build environment, i.e., not arbitrary rewritting > > but a precise one. What has changed in this regard to make it serious? > > Allow me to focus on this issue, because it sets yada apart from > debhelper, cdbs or packages without any helpers. I will CC the bug in > question. > > Firstly, the scope of the rewriting is greater than merely the > Build-Depends field. The entire control file in the source package > (not just in the binary packages) is regenerated from debian/packages > during each build - indeed, so is debian/rules. Any manual > modifications to debian/control or debian/rules are likely to be > overwritten when 'debclean' is run. Yep, it basically means that the debian/rules and debian/control are in fact embedded in the debian/packages file and are written from it. So, the rule that the build process must not modifiy the control file for yada should be read as "must not modify the packages file" which is the origin from them. The fact that ftp-masters had neither banned yada packages nor sent further respones to that bug make me suspect that's how rule is being applied in case of yada, but I may be wrong, of course. > Secondly, consider the case where yada is updated during the course of > a release cycle, and a package using yada is not rebuilt before the > release: > > 1. yada-0.55-1 is uploaded. > 2. foo-0.1-1 is uploaded - Build-Depends: yada (>= 0.55) > 3. yada-0.56-1 is uploaded. > 4. Release happens. > 5. Security bug is found in the 'foo' package. > > Then the security update for 'foo' will be given a different > Build-Depends line from foo-0.1-1. If any other details of how > control or rules files are generated have changed in yada 0.56, then > these will also be applied to the security update. I don't think this situation is even possible: you have to freeze things before release, and that includes helpers. And if you have to do that because a grave problem on the helper affecting packages build process you should issue binNMUs on the packages using it to ensure the problem is solved with the new helper version before releasing. > This makes it difficult to produce a minimal diff for a security > update (or even an NMU in unstable) for a package using yada, and > increases the risk of unintentional changes. The same problems do not > occur with other methods of building packages, because the source > packages are not automatically modified. Yes, I understand the problem, but if the release is done properly that should not happen (TM), and we should trust our Release Team ;) regards, -- Ricardo Mones ~ You have the capacity to learn from mistakes. You'll learn a lot today. /usr/games/fortune
Attachment:
signature.asc
Description: Digital signature