On Sat, 5 May 2012 11:34:45 +0200 Dominique Dumont <dod@debian.org> wrote: > > i.e. not rebuild all 400 necessarily but to identify those which of > > those 400 do not already build-depend on the packages you removed and at > > least let the maintainers of the packages know that your change may > > reveal an RC bug in their packages. > > Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have > only 2 active people. I don't count myself as active in sdl team as I mostly > do package reviews and upload. We just don't have the time to perform what you > suggest just to compensate for easy-to-fix packaging mistakes. It really isn't that much work to scan through apt-cache rdepends and then check that against Sources.gz to get a list of collated Build-Depends. If the new team don't have time to write and run a short script then maybe the package would have been better off without the upload. Maintenance is not about being an automaton with a GPG key and a package review should include the implications of the changes on other packages which use the package being reviewed. > > > Unfortunately, some package did rely on this "extra" dependencies and > > > went ftbs [2]. > > > > ... which could, arguably, be jointly your fault as this could have > > been handled cleanly if done so in advance. > > Not my fault, nor current team's fault: this mistake was done years ago. We > are still cleaning up what we found. The original mistake, yes, but then the package didn't FTBFS. Those failures arise from the change you made. Albeit for sensible reasons but not *compulsory* reasons - there is no requirement to drop unnecessary build-dependencies, the requirement is not be lacking build dependencies. IMHO it's perfectly acceptable to have redundant build-dependencies *where removing them would cause breakage elsewhere* as this gives an opportunity to get those issues fixed smoothly. What has been achieved by removing those build-dependencies? Your package is a bit cleaner and Debian is a bit more broken. Gee, thanks. Less work for you, more work for the rest of us and without even a heads-up or thought of the consequences. Sounds like you're taking more than just Lucas for granted. I don't seek to diminish the problems in the other packages - as Russ points out, those packages are already ignoring Policy - but solving those Policy issues without generating RC bugs en masse would have been so much better. In effect, the package upload has induced a mass bug filing without any checks or attempts at detection let alone prevention, in the expectation that someone else will not only pick up the pieces but identify where things have been broken by *your* change. To not even bother checking what might break until *AFTER* the upload is beyond careless, it is presumptive. Maintainers of libraries have responsibilities to the maintainers of packages which are reverse dependencies - those include handling things like SONAME changes API breakage cleanly and alerting them to upcoming changes with sufficient time that packages can be adapted without breakage. If time is allowed and nothing happens, so be it, but to upload and then confess to the breakage only after packages have failed to build is poor. > Actually, the whole point of my mail was to gather real data from work already > done. Thanks to Lucas, we know about failing packages. Too bad we don't know > about succeeding packages. That would have been fine but the upload had been made without this check being done. This could have been so much better if the discussion had preceded the upload. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgp7jSYkh6xNA.pgp
Description: PGP signature