On Thu, Aug 04, 2011 at 12:03:10PM +0100, Tim Retout wrote: > On 4 August 2011 10:07, Ricardo Mones <mones@debian.org> wrote: > > 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. > > Right; but the helper being frozen does not mean that we binNMU every > package depending on it? Err, I think I lost something here... I meant you binNMU if you have to upload a new helper version to fix something affecting build process, i.e., something you have to really verify. I think this applies to every helper in the situation you described, not only yada. > See for example: > yada version 0.55 is in stable. > aylet - Build-Depends: yada (>= 0.53) in stable. > cvsconnect - Build-Depends: yada (>= 0.48) in stable. > etc. > > If you try rebuilding these in a stable chroot, you'll get a different > debian/rules and debian/control in the new source package. If yada > were actively maintained, the changes could be a lot more drastic. According the bug response, the only change to build depends should be the yada version number (which would become 0.55), and rules should be the same. If that's not true then I would agree the problem is more serious. > The best, of course, are found in experimental: > libhttp-davserver-perl: Build-Depends: yada (>= 0.21) > securecgi: Build-Depends: yada (>= 0.23) and FTBFS because automake1.8 > no longer exists - I'll go and file a bug. Yeah, same as before, but what I see here is packages with a lazy or inexistent maintainer, which should have uploaded some update so the yada version numbers were current. As said not a yada problem itself. Imagine some maintainer using debhelper which refuses to bump compat level, do we remove debhelper or the package? Like is already done with other changes, make usign yada < $testing_ver - 1 (for example) a serious bug and things would improve (either packages are fixed or removed). Futhermore, this can be automated :) > I strongly suspect the ftp-masters will not allow packages through NEW > that contain yada, but that it's not in the FAQ because not that many > people bother to try. Umm, that could be too :) any ftp-master around to confirm? -- Ricardo Mones ~ Physics is like sex: sure, it may give some practical results, but that's not why we do it. Richard Feynman
Attachment:
signature.asc
Description: Digital signature